2

Seam conseille d'utiliser un étendu contexte dans un Stateful Session, afin d'avoir une persistance gérée par Seam.Procédures de transactions gérées par couture

Je ne sais pas si les conseils ci-dessus ont des implications sur la façon dont nous voulons avoir des transactions gérées par Seam. C'est parce que notre architecture est différente. Nous avons le contexte de persistance suivante dans un Stateless EJB:

@Stateless 
@TransactionAttribute(TransactionAttributeType.REQUIRED) 
public class CrudServiceBean implements CrudService { 

    @PersistenceContext(type = PersistenceContextType.TRANSACTION) 
    private EntityManager em; 
... 
} 

Nos OTI invoquent les CrudServiceBean ci-dessus sont Apatrides (EJBs certains d'entre eux sont également des composants Seam) avec @TransactionAttribute (TransactionAttributeType.REQUIRED). Ainsi, nos transactions sont traitées par le conteneur (WebLogic) et non Seam.

Cependant, nous avons maintenant besoin de satisfaire le scénario suivant: Nous devons avoir une des méthodes composant Seam-frontal (non EJB) invoquer plusieurs DAO (EJB) et envelopper tous dans une seule transaction. Si je comprends bien, nous devons avoir des transactions gérées par Seam. Peut-on avoir des transactions gérées par Seam comme dans le scénario que j'ai décrit, sans avoir de contexte de persistance géré par Seam? Ou sont les deux hors de propos?

Répondre

2

Comme dit

Nous avons besoin d'un composant Seam frontal méthodes et wrap (non EJB) invoquer plusieurs DAO (EJB) tous en une seule transaction

Mais

Nos transactions sont gérées par le conta iner - également appelée Transaction gérée par conteneur (Le conteneur se charge d'appeler begin et commit méthode utilisée par chaque transaction ressources gestionnaire sous-jacent)

La première question est que vous avez un scénario dans lequel un non-EJB appelle plusieurs DAO, chacun un EJB. Vous pourriez penser

@Name("nonEjbComponent") 
public class NonEjbComponent { 

    private @In DaoEjbComponent daoEjbComponent; 
    private @In OtherDaoEjbComponent otherDaoEjbComponent; 
    private @In AnotherDaoEjbComponent anotherDaoEjbComponent; 

    private @In UserTransaction userTransation; 

    public void wrapperAllOfThem() { 

     userTransation.begin(); 

      daoEjbComponent.save(someEntity); 
      otherDaoEjbComponent.update(otherEntity); 
      anotherDaoEjbComponent.delete(anotherEntity); 

     userTransation.commit(); 

    } 

} 

Mais la spécification Java EE 3.0 états

Le haricot d'entreprise avec soit gérée par le bean ou la démarcation des transactions gérées par le conteneur doit être un haricot de session ou un bean géré par message.

Donc, vous ne pouvez pas utiliser le scénario ci-dessus.Et parce que tous vos OTI utilisent les transactions gérées par le conteneur, la spécification Java EE ne vous permet pas d'utiliser conteneurs gérés et gérée par bean Transaction en même temps

La solution est donc

Enveloppez tous les DAO dans un bean de session EJB Stateless dont la transaction est gérée par le conteneur. Il se comporte comme un composant délégué

@Stateless 
@TransactionAttribute(TransactionAttributeType.REQUIRED) 
@Name("wrapperStateless") 
public class WrapperStatelessImpl implements WrapperStateless { 

    private @In DaoEjbComponent daoEjbComponent; 
    private @In OtherDaoEjbComponent otherDaoEjbComponent; 
    private @In AnotherDaoEjbComponent anotherDaoEjbComponent; 

    public void wrapperAllOfThem() { 

     daoEjbComponent.save(someEntity); 
     otherDaoEjbComponent.update(otherEntity); 
     anotherDaoEjbComponent.delete(anotherEntity); 

    } 

} 

Et à l'intérieur de votre composant non EJB, utilisez

@Name("nonEjbComponent") 
public class NonEjbComponent { 

    private @In WrapperStateless wrapperStateless; 

    public void wrapperAllOfThem() { 
     wrapperStateless.wrapperAllOfThem(); 
    } 

} 
+0

J'essaie simplement de comprendre ici. Cela signifie-t-il que si j'ai des composants de couture non-EJB, la couture ne peut pas gérer la transaction et que je dois suivre un modèle similaire décrit ici? – Arash

Questions connexes