Re: Gestion des exceptions en JTA / JPA

Pas de solution ideale/miracle comme souvent, je confirme.
Je crois même me souvenir que nous avons déjà discuté de ce sujet précis sur
la liste.

Le flush en fin de tx permet bien d'améliorer les perfs (jamais benché
toutefois).
Je pense dc que la meilleure (ou disons la moins mauvaise) solution serait
effectivement de changer la façon habituelle de gestion des erreurs bd par
un système de callback configuré en fonction de l'erreur remontée par le
sql.

Baptiste
Le 24 mars 2011 13:50, "Régis Le Brettevillois" <[email protected]> a
écrit :
> 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
>
>