Re: Gestion des exceptions en JTA / JPA

 On Thu, 24 Mar 2011 13:19:45 +0100, Dominique Gallot 
 <[email protected]> wrote:
>>L'utilisation du flush de cette manière est déconséillée
>
> Cela dépends. En fait le problème n'est pas tant les performances
> que les locks de rows.
> Dans les databases transactionnelles on lock le row (ou parfois les
> pages de rows sur les anciennes db sybase) lors d'une modification de
> données.
>  Si tes transactions sont longues ca pose un problème.
> D'un autre coté, déférer les modifications lors d'un flush pose
> des problèmes avec les contraintes d'intégrités de la DB.
> De plus comme tu le dit, ce n'est plus le code qui insert le row qui
> reçoit l'exception mais le code qui appelle le flush/commit.
>  Notes que ce comportement existait aussi avec les database, vu que
> l'on peut retarder le check des contraintes au niveau du commit.
> Donc comme toujours il n’y a pas de bonne façon de faire, mais des
> façons différentes qui comporteront des contraintes différentes.
>

 Effectivement, le problème est essentiellement lié à l'isolation et 
 à la cohérence de la transaction.
 Maintenant, l'opération de flush (et non pas de commit) devrait se 
 comporter de la même manière qu'un insert/update SQL en mode 
 autocommit off.
 Je ne connais pas l'implémentation de TopLink donc c'est difficile de 
 dire si elle est équivalente, et si elle "transactionnelle" ou pas.
 L'intérêt d'un moteur de mapping comme TopLink ou Hibernate, c'est 
 justement d'éviter de pousser des données vers la base tant qu'on a 
 pas terminé la transaction. Donc si le flush peut potentiellement 
 répondre à ta problématique, il n'est pas trop dans l'esprit des 
 mécanismes mis en oeuvre.

>>Sinon je verrais bien un convertisseur d'exception au niveau d'un
> intercepteur au dessus de la couche service ?
>

 Si vous considérez que le boulot de pousser l'information vers la BDD 
 est du ressort du framework Toplink on arrive donc au problème 
 évoqué.
 Les erreurs de contraintes (unicité, dépendances, etc) apparaissent 
 donc au moment du commit, ce qui n'est pas facile à gérer puisque 
 généralement c'est Spring qui s'en occupe (je suppose que vous 
 utilisez le mode de transaction implicite).
 Le framework Spring fournit une interface qui permet de participer au 
 protocole transactionnel et donc de potentiellement intercepter les 
 erreurs au moment du commit/rollback. Si je ne me trompe l'interface est 
 TransactionManager qui dans le cas de TopLink sera injectée sous la 
 forme TopLinkTransactionManager, pour intercepter les exceptions il 
 devrait être possible d'implémenter une version de cette interface qui 
 délèguerai au TopLinkTransactionManager.
 

 Régis