Discussion :

[nean_j]

en référence à cela : http://blog.developpez.com/djo-mos?t...nage_par_sprin

Donc ma première question sur ce billet :

Après plusieurs testes et péripéties j'ai réussi à faire tourner quelques chose, par contre il y a quelque chose que je ne comprend c'est pourquoi dans mon service, annoté avec @service les méthode annotés avec @transactionale ne sont pas prises en comptes, il faut que je mette cette annotation au niveau de l'implémentation de mon dao...

Auriez vous des informations par rapport à cela ?

Et une première réponse :

En fait, il est possible d'utiliser @TRansactional sur les interfaces, mais il faut que tu utilises les DynamicProxy du JDK, au lieu du proxying complet offert par les libs comme cglib, or, le proxying du JDK est très limité" et n'est pas vraiment utile en réalité.
Donc, c'est pour cela que ça ne marche pas dans ton cas: car Spring utilise cglib pour le proxying des classes.
Pour ce cas, la limitation vient du fait que les annotations ne sont pas héritables (de par leur définition), donc, la classe proxiée ne voit pas les annotations de l'interface.

Donc en fait je n'ai pas tout saisi dans cette affaire, on me propose de mettre le @Transactional au niveau des interfaces mais cela utilise la lib de la jdk et non celle de cglib (proxying complet)... OK jusque là ça va...

Dans ce cas là par contre je ne vois pas la différence, quel serait le meiux à faire alors ?
Sachant que j'ai une méthode de mon service qui effectue plusieurs opérations sur la base de donnée. Donc j'aurai voulu englober cette méthode comme transaction et non uniquement les différentes méthodes de mes DAO appelées pour ensuite éventuellement effectuer un rollback sur toute la transaction par exemple... Ou sinon j'effectue à la main de rollback ?

Quelle serait la meilleure méthode dans ce cas ?

PS : Je suis en environnement J2SE uniquement.

merci d'avance.

[julien.dubois]

De manière générale on recommande d'utiliser les proxy du JDK plutôt que CGLIB :
http://static.springframework.org/sp...l#aop-proxying

C'est aussi ma recommandation personnelle. Cela vous force à faire des interfaces, mais c'est une bonne chose de toute manière.

A partir de là, si vous mettez un @Transactionnal sur une méthode d'un bean "métier", la transaction sera effective pour les DAOs que vous appelez depuis cette méthode. Cela fera donc bien ce que vous cherchez à réaliser, une transaction globale pour tous vos DAOs, avec un rollback de l'ensemble automatique en cas de souci.

[djo.mos]

Salut,
Au risque de répéter ce que Julien a dit, la déclaration des limites des transactions se fait bel et bien dans la couche service et pas dans les DAOs, comme je l'ai dit dans le billet:

Passons maitnenant à la gestion des transactions.
Je ne l'ai pas mis dans le DAO (comme on le faisiat en mode non managé) car ça n'a pas de sens.
Une transaction doit englober une opération de la couche métier, et nnon pas dans la couche DAO pour être vraiment utile et garantir un état homogène des données.

[nean_j]

Merci pour ces réponses, maintenant je comprend mieux, le problème que j'avais était que j'avais vu des exemples qui ne respectait pas cela et qui mettait des @transactional dans les dao, ça me semblait bien bizarre ... Après les interfaces ne me posent pas du tout de problème au contraire quand nous sommes plusieurs à travailler sur un même projets avec différents modules cela est totalement pratique, après d'un point de vue architecture ça permet de bien dissocier les différentes couches et de pourvoir éventuellement modifier le code après sans à avoir tout à revoir.

Sinon j'ai une ou deux autres questions :
-Petite question pour les dao, est ce que le @Repository est héritable ? Car j'ai fait des dao génériques, et cela m'éviterait de le mettre dans toutes les classes dao définies.
-Question plus importante, désolé je suis encore débutant avec Spring, mais je voulais savoir à quoi servent exactement et dans quels cas on indique des pointcut ? En regardant cette doc : http://java.developpez.com/faq/sprin...integrationJpa
J'ai vu que ça apparaissait dans la partie de condensé mais sans une seule explication.

Merci d'avance.

[djo.mos]

Bonjour,

-Petite question pour les dao, est ce que le @Repository est héritable ? Car j'ai fait des dao génériques, et cela m'éviterait de le mettre dans toutes les classes dao définies.

Non, ça n'a pas de sens ça. C'est très différent de @Transactional par exemple, car là (@Repository et donc @Component) on est en rtain de définir u nbean Spring, ou encore des propriétés spécifiques à un bean (le id par exemple, etc.), qui ne sont pas héritables ou partageables entre plusieurs, donc, il faut bel et bien annoter chacun de tes DAOs concrets avec @Repository.

[julien.dubois]

Le @Repository n'est pas héritable (lui-même n'a pas l'annotation @Inherited). De toute manière l'idée c'est d'annoter toutes les classes DAOs, donc je ne suis pas certain que ce soit une bonne chose de remplacer cela par de l'héritage (c'est beaucoup moins souple, on ne peut hériter qu'une fois!).
Pourquoi utiliser l'AOP plutôt que les annotations? Grande question!! En fait c'est intéressant si tu as un pointcut qui te fait gagner beaucoup de temps. Par exemple, dire que toutes les méthodes "create" sont transactionnelles.
Personnellement pour les transactions je préfère définir mes transactions une à une, pour avoir plus de contrôle sur chaque méthode : je peux changer le niveau d'isolation ou en marquer une "read-only" si j'ai envie. Mais c'est juste une opinion, et cela dépend de tes besoins et de ton projet.

[julien.dubois]

>djo.mos, nos posts sont arrivés en même temps!! Heureusement nos réponses concordent :-)

[nean_j]

ok ok bon c'est bien ce à quoi j'avais présumé... Merci beaucoup

Sinon une dernière petite question le read-only doit être pour les transactions sans opération de modification, uniquement des recherches dans la base je suppose, mais par contre le niveau d'isolation je ne vois pas à quoi ça sert ?

[julien.dubois]

Oui le read-only peut améliorer les perfs lorsque tu es en lecture seule (je dis bien "peut", ça dépend entre autres de ta base de données).
Pour les niveaux de transaction c'est plus compliqué, le mieux c'est d'aller voir sur un site comme Wikipedia qui t'expliquera :
http://en.wikipedia.org/wiki/Isolati...mputer_science)

[nidget]

Oui le read-only peut améliorer les perfs lorsque tu es en lecture seule (je dis bien "peut", ça dépend entre autres de ta base de données)

Le read-only est une optimisation pour JTA. Cela n'améliore (éventuellement) les performances que dans le cas de transactions distribuées (sur plusieurs sources) pour autant que ces sources répondent toutes à la norme XA. Si c'est le cas, le transaction manager peut (pas d'obligation) ne pas effectuer la procédure de "two phase commit" à la fin de la transaction. D'où gain de performance sur les transactions distribuées qui ne font que de la lecture... un cas pas très très courant dans la réalité, mais bon, ça fait bien de le mettre (je l'utilise, mais plus souvent dans le but de "documenter" le code, en indiquant que la méthode annotée n'est pas censée modifier de données).