Discussion :

[kisitomomotene]

Salut à tous

considérons par exemple ce bloc de code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[hhfr]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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(...);
   }
}