[Info]ibatis pas mure

Bonjour;

j'utilise Ibatis depuis presque 1 ans et maintenant sur un projet assez consequent qui demande des performances et pose des problèmes au niveau de la monté en charge du aux nombreuses requetes DB.
Je pense que nous avons résolu le pb en utilisant DBCP au lieu de JDBC et en utilisant au maximum le cache d'ibatis et OSCache mais aujourd'hui je recois un mail de la direction informatique.

"ibatis est trop immature pour une utilisation en production si vous voulez faire de l'orm une seule solution hibernate"

je voudrais avoir votre avis. Sachant que ibatis ne fait pas de l'orm et cela n'est pas mon objectif.

Des arguments?


[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

Tu veux quoi des arguments pour ou contre ?
Comme tu l'a dis iBatis ne fais pas du vrai ORM. Maintenant la question à ce poser est qu'est que qui est trop lent. Et qu'est ce qui motive ce mail. Peut-être est ce simplement un réaction à un evenement précis qui mérite d'être analysé et optimisé. Hibernate n'est pas plus rapide que iBatis, de toute facon à la fin ce n'est ni plus ni moins que du SQL. Donc si les indexs sont foireux ou la DB mal configurer. Le résultat sera le même.

Donc a ta question je retourne une question qu'est ce qui est lent ?

Citation:

---

Envoyé par ze_key

Tu veux quoi des arguments pour ou contre ?
Comme tu l'a dis iBatis ne fais pas du vrai ORM. Maintenant la question à ce poser est qu'est que qui est trop lent. Et qu'est ce qui motive ce mail. Peut-être est ce simplement un réaction à un evenement précis qui mérite d'être analysé et optimisé. Hibernate n'est pas plus rapide que iBatis, de toute facon à la fin ce n'est ni plus ni moins que du SQL. Donc si les indexs sont foireux ou la DB mal configurer. Le résultat sera le même.

Donc a ta question je retourne une question qu'est ce qui est lent ?

---

en fait il y a pas mal de requetes qui sont exécutés et nous n'avons pas trop trouvé de moyen pour éviter des blocages dans le cas ou la DB n'arrive pas à les traiter dans les temps voulu.
en solution nous avons utiliser un treadPool mais celui ci sature nous avons changé jdbc pour dbcp afin d'utiliser une validation query etc...
tu vois le pb ?

moi je pense qu'ibatis est mature pour la production, du coté de la base je sais qu'elle est mal designé mais c'est plus le nombre de requetes énorme qui peche ici que le volume de données
Bref avant de passer sous ibatis il n'y avait pas ses plantages car si une requetes ne s'éxécutait pas JDBC la détruisait. Avec ibatis on n'a pas réussi à mettre sa en place

Salut,

J'ai utilisé Hibernate comme iBatis dans des projets d'envergure.
Je pense que l'un comme l'autre ont leurs intérêt.

Hibernate est un ORM, le SQL qu'il génère est je pense assez 'crade' tandis que iBatsi, qui est un DaoMapper, permet d'écrire soit même le SQL et donc d'optimiser ses requête.

Pour moi, si tu as des problèmes de performances avec iBatis, tu dois travailler sur l'optimisation de tes requêtes ou l'optimisation DB, mais le passage à Hibernate ne résoudra pas tes problèmes

Quelle est ta base de données ?
Avez-vous mené une campagne de bench complet de l'UI à la BD en passant par les trames réseaux et tout le toutime ?

DBCP c'est une chose, JDBC en est une autre, cela ne change rien aux performances SQL de toutes manière, juste la manière de localiser, utiliser et recycler les connexions.

Si tu utilise Oracle, je te conseil d'utiliser un outil comme Spotlight pour monitorer le serveur.

Autres petites choses importantes, les serveurs physiques sont-ils bien dimensionnés ? Le tuyau est-il assez gros ? Les processus de ta BD et de ton serveur d'applications ne sont t'ils pas collés au plafond à 100% ?

Oui ca ma plus l'air d'être un probleme d'architecture que de iBatis. Tu aura les même problème avec hibernate dans ce cas.
C3P0 te permet de faire du pooling et de mettre les query en pipe. Une solution est de mettre des query timeout sur la db pour degager les query trop longues ou stupides (query user qui retourne 9000 rows, personne ne lit 9000 rows).

et au niveau maturité
peut on dire qu'ibatis n'est pas mature pour une utilisation en production sur une appli qui est critique au niveau des performances ???
c'est ca que j'ai du mal à comprendre venant d'un directeur technique

Directeur technique ou clampin de base, celui qui dit qu'Ibatis n'est pas mature n'as rien compris à IBatis !

Avant toute chose, IBatis est un framework permettant d'externaliser les requêtes JDBC et offre un mapping simple en lecture/mise à jour ainsi qu'un mapping avancé en lecture.

L'un de ses avantages et d'offrir une méthode très simple pour les query dynamique bien que celle-ci soit encore loin de QBS d'Hibernate.

Mais je confirme, IBatis n'est pas un ORM même s'il s'en approche.

De plus, contrairement à Hibernate ou JDO, IBatis ne génère aucune requêtes SQL donc, pour faire simple et vulgaire, si ça rame, c'est à cause de la requête donc, du développeur ou du DBA ! (Si il y a un DT, je suppose qu'il y a un DBA...)

Tu n'a pas répondu à mon message précédent, quelle base utilise tu et qu'en est il des performances globales ?

Citation:

---

Envoyé par grosFab

et au niveau maturité
peut on dire qu'ibatis n'est pas mature pour une utilisation en production sur une appli qui est critique au niveau des performances ???
c'est ca que j'ai du mal à comprendre venant d'un directeur technique

---

Toutes les applications sont critique...
Surtout du point de vue d'un DT :)

Citation:

---

Envoyé par Alwin

Directeur technique ou clampin de base, celui qui dit qu'Ibatis n'est pas mature n'as rien compris à IBatis !

Avant toute chose, IBatis est un framework permettant d'externaliser les requêtes JDBC et offre un mapping simple en lecture/mise à jour ainsi qu'un mapping avancé en lecture.

L'un de ses avantages et d'offrir une méthode très simple pour les query dynamique bien que celle-ci soit encore loin de QBS d'Hibernate.

Mais je confirme, IBatis n'est pas un ORM même s'il s'en approche.

De plus, contrairement à Hibernate ou JDO, IBatis ne génère aucune requêtes SQL donc, pour faire simple et vulgaire, si ça rame, c'est à cause de la requête donc, du développeur ou du DBA ! (Si il y a un DT, je suppose qu'il y a un DBA...)

Tu n'a pas répondu à mon message précédent, quelle base utilise tu et qu'en est il des performances globales ?

---

C'est du SQL server 2003 pour les perfs j'ai demandé au service DB de monitorer la base