Re: Gestion des exceptions en JTA / JPA

>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.

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

Il est assez dommage que lors du design de JDBC ils n’ont pas enrichi les
SqlExecption pour avoir par facilement les contraintes qui ont été
enfreintes. Cela aurai evité ce genre de brol :
http://www.coderanch.com/t/301730/JDBC/java/we-know-exact-position-exception(
le post de David Harkness )

Dominique
2011/3/24 Sebastien Cesbron <[email protected]>

> Salut la liste
>
> J'ai discuté avec des collègues de problèmes de gestion des exceptions avec
> JTA / JPA et vu que ça fait un petit moment que je n'ai pas pratiqué, je me
> disais qu'il y aurait peut être des gens plus éclairés que moi dans la
> liste.
>
> On a une architecture en couches avec globalement une couche Service, une
> couche métier et une couche DAO.
>
> Les services gèrent les transactions avec des annotations (spring en
> l'occurence). Les DAO gèrent la mise en base via un outil de mapping
> (toplink natif chez nous mais ça pourrait être du JPA).
>
> On part sur un cas simple de traitement d'une violation de contrainte
> d'unicité sur le nom d'une personne lors de l'insert en base.
>
> En jdbc, j'appelle le dao, l'insert est fait et le dao renvoie l'exception
> qui peut être traitée précisément (on sait que c'est sur la personne car on
> appelle le dao personne) et convertie en quelque chose de plus métier.
>
> Avec un outil de mapping, le dao ne lève pas d'exception car lors de
> l'insert le flush en base n'est pas fait, c'est lors du commit au niveau de
> l'annotation spring sur le service que l'exception va être levée.
>
> Comment gérer cela proprement pour qu'au final celui qui appelle le service
> ait une exception métier claire et précise ?
>
> Les personnes avec qui je discute et qui sont habituées à faire de jdbc,
> aurait tendance à forcer un flush en sortie de chaque méthode d'écriture
> d'un DAO. L'utilisation du flush de cette manière est déconséillée : est-ce
> uniquement un pb de performance ou bien y a t'il autre chose ? Est-ce que
> certains d'entre vous ont mis en place cela ? si oui avez vous rencontrés
> des problèmes ?
>
> Sinon je verrais bien un convertisseur d'exception au niveau d'un
> intercepteur au dessus de la couche service ? Est-ce que certains ont déjà
> fait cela ? quels problèmes ?
>
> Voilà ma question existentielle du jour si certains ont un avis je suis
> preneur
>
> A+
> Seb
>