Discussion :

[MaryTerra]

Bonjour,

J'ai un soucis d'optimisation d'un batch. J'ai un traitement qui récupère des données dans un objet Client puis les enregistre en base de données. La récupération des données est assez rapide mais le commit en base prend un temps exponentiel.
Avec des logs aux bon endroits on se rend compte que les 300 premiers clients sont commités en 2 minutes, les 300 suivants en 5 minutes, les 300 d'après en 8 minutes, 11 minutes pour ceux qui suivent, puis 15 minutes, etc.
Chaque client est traité dans une transaction indépendante qui commence pour lui et commit avant de passer au suivant. Chaque transaction est par contre ouverte dans la même session hibernate.

Est-ce que quelqu'un aurait une idée sur le pourquoi de ce temps exponentiel d'un commit au suivant ou connaitrait une application à utiliser pour auditer ma base de données et savoir les actions à faire dessus en terme d'index ou autre qui pourrait accélérer le traitement ?

Merci.

Java J2EE
Hibernate
BDD Oracle

[Logan Mauzaize]

Quelques rappels :

• Une session Hibernate = Une connexion = Une série séquentielle d'opération.
• Une transaction = Une série séquentielle d'opération qui forme une opération fonctionnelle "cohérente"
• Créer une transaction au sein d'une autre sert à pouvoir annuler une partie seulement de la transaction.
• Valider une transaction consiste à valider TOUTES les transactions de la même connexion.

Ouvrir une transaction doit se faire pour un seul utilisateur dans le cas où l'on veut pouvoir annuler qu'une partie de la transaction en cas d'erreur.

Du coup tes transactions ne sont pas isolées et tout le monde utilise la même. Et quand tu comit, ça comit toutes les transactions en même temps.

[MaryTerra]

Merci d'avoir répondu :-)

Donc si j'ai bien compris ta réponse, chaque commit recommit toutes les transactions ouvertes précédemment... ça explique pas mal le coup du temps exponentiel...

Le problème c'est que j'ai besoin de pouvoir annuler une partie des transactions s'il y a un problème sans que ça annule tout.

Concrètement la session ou connexion est ouverte pour tout le batch, qui peut être considéré comme "l'utilisateur". Jusque là ça semblait cohérent.
Ensuite pour chaque client, il y a commencement d'une transaction, différents accès à la base, puis commit de cette transaction et rollback si problème. L'idée étant que s'il y a un problème avec un client, les précédents et/ou suivants qui ne posent pas de problème sont bien enregistrés en base de données.

Faudrait-il plutôt ouvrir une session pour chaque client (ou éventuellement groupe de client) ?
Ou faut il faire autrement pour commit les données au fur et à mesure sans que les commit ultérieurs cherchent à recommit les transactions précédentes ?

Merci de votre aide.

[Logan Mauzaize]

Plutôt que créer une transaction tu dois créer une session. Enfin tu peux réutiliser les sessions mais assurent toi que tu n'as pas déjà une transaction en cours dans celle-ci ;-)

[MaryTerra]

Je viens d'essayer d'ouvrir une session pour chacune de mes transactions et cela a résolu mon problème !

Merci beaucoup. Je n'aurais pas pensé que le commit d'une transaction recommitait toutes les transactions de la même session.

Merci ! :-D