Quelles bonnes pratiques pour utiliser les transactions "en ligne"?

Salut à tous

considérons par exemple ce bloc de code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

@statefull @Namer class MyClass extends IMyclass{   @TransactionAttribute(requireNew) public void myMethod1(){ ... }   @TransactionAttribute(requireNew) public void myMethod2(){ ... }   public void myMethod(){ myMethod1(); myMethod2(); }   }

---

En exécutant la méthode "myMethod()" les méthodes "myMethod1()" et "myMethod2()" ne vont pas s’exécuter dans le contexte des transactions définies (dans notre cas "requireNew"). Pour cela, il faudrait extraire la méthode "myMethod()" dans une autre classe.

Code:

---

1 2 3 4 5 6 7 8 9 10

class ArtificialClass {   @Inject Myclass myClass; public void myMethod(){ myClass.myMethod1(); myClass.myMethod2(); } }

---

Logiquement la méthode "myMethod()" doit se trouver dans la classe "MyClass". Mais à cause d'un problème purement technique ( exécution des transactions), je me trouve obligé de la placer dans une classe "artifcielle" qui n'a aucune signification "métier" et qui est utiliser juste pour contourner un problème technique. Connaissez vous une façon plus élégante de résoudre ce problème? merci

Je m'etais fait la même réflection que toi, je te mets mon poste et mes constatations
http://www.developpez.net/forums/d11...-asynchronous/

Mais en gros, le conteneur ne détecte les annotations que sur les business method.
Mais qu'est ce qu'une business method ??? C'est une méthode appelée de l’extérieur de l'ejb. Et seulement à ce moment la. Si une méthode est appelée en interne et en externe, seul l'appel externe considère celle ci comme une business method.

Ceci est vrai pour les transactions comme tu as vu.
Ceci est vrai pour les annotations @Asynchronous
Ceci est vrai pour les annotations @Lock

Et j'en oubli surement ici.

Pour la bonne pratique, ben je sais pas plus que toi, je découpe mes EJB en plusieurs. Pour l'instant cela va bien.
Pour les singletons et la gestion des lock par contre, j'ai trouvé/fait un truc élégant (je trouve), je te mets cela, si cela t'inspire. En effet pour les @Singleton avec des Locks seuls les appels externes, encore une fois, considèrent les annotations donc, pas moyen de faire un appel Lock.WRITE à partir d'un appel Lock.READ ou alors faire une section synchronized
Solution faire un sateless qui gère la mécanique des accès concurrentiels.
Et ainsi éviter les sections synchronized

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

@Singleton public class SingletonBean { @Lock.READ public boolean isLoad(...) {} @Lock.WRITE public Object load(...) {} @Lock.READ public Object read(...) {} }   @Stateless @LocalBean public class ResourceServices { @EJB SingletonBean singbean; public Object read(...) { if(!singbean.isLoad()) return singbean.load(...); return singbean.read(...); } }

---