Comment UserTransaction se propage?

J'ai un stateless bean avec bean-managed transactions, et une méthode comme ceci:

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class ... {

    @Resource 
    private UserTransaction ut;
    @EJB 
    private OtherStatelessBeanLocal other;

    public void invokeSomeMethods() 
        ut.begin();
        ...

        //invoke other bean's methods here.
        other.method();

        ...
        ut.commit();

    }

}

Donc comment le UserTransaction se propager à l' OtherStatelessBeanLocal bean?

source d'informationauteur Truong Ha

  1. 32

    La UserTransaction objet est un objet fourni par le conteneur qui encapsule l'accès aux appels d'API que le conteneur utilise en interne, plus précisément javax.des transactions.TransactionManager. Le TransactionManager a des méthodes comme begincommitrollback et javax.transaction.Transaction getTransaction()

    Sous les couvertures, la TransactionManager va utiliser un ThreadLocal ou technique similaire à suivre le courant de l'état des transactions avec le fil. ThreadLocals sont des objets très simples qui peuvent facilement être décrite comme une static HashMap qui utilise le nom du thread comme clé et un objet de votre choix comme valeur. Tant que vous restez dans le même thread, vous pouvez obtenir l'objet à partir de n'importe quel point dans l'invocation de la chaîne. C'est l'une des raisons pour lesquelles il n'est pas autorisé à prendre le départ de threads dans un environnement Java EE.

    De propagation de sécurité fonctionne de manière similaire, comme le font JNDI recherches qui comme par magie le point à droite du module ou composant java:comp/env espace de noms. Ligne de fond est que vous ne pouvez pas mettre en œuvre d'un serveur d'application sans ThreadLocals. La Propagation des sons plus actif qu'il est, lorsque en vérité, il est simplement l'acte de ne pas laisser le fil de sorte que le conteneur et l'ensemble des acteurs peut encore trouver vos "trucs".

    De retour dans la gestion des transactions termes, l'objet d'un TransactionManager permettra de suivre dans ses ThreadLocal généralement mettre en œuvre (directement ou indirectement) à la fois la Transaction et TransactionSynchronizationRegistry interfaces. Entre ces deux interfaces, le conteneur a tous les crochets, il doit suivre DataSources, EntityManagers et d'autres ressources dans la transaction en cours sur votre compte. Ces interfaces permettent également le conteneur à offrir des rappels comme SessionSynchronizationainsi que les moyens de faire d'autres choses en votre nom lors de l'achèvement de la transaction, tels que bouffées de chaleur/fermeture EntityManagers, l'envoi de JMS, messages en attente, et la persistance de tous les compteurs créé par votre application dans le cadre de la transaction.

  2. 4

    Basée sur la spécification EJB, vous ne pouvez pas passer un contexte de transaction à partir d'un haricot (dans ce cas, votre classe principale ... ) à l'aide de transaction programmatique dans un autre bean (dans ce cas, d'autres) à l'aide de transaction programmatique

  3. 0

    Pour EJB3 vous définissent normalement transaction propagation avec le @TransactionAttribute annotation.

    La transaction par défaut de l'attribut pour tous les EJB 3.0 applications:

    Si un client appelle le haricot d'entreprise de la méthode alors que le client est associé à un contexte de transaction, le conteneur appelle le haricot d'entreprise de la méthode dans le contexte de transaction.

    Le doc de pour le type d'opération sont ici: http://download.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.html

    N. B. contexte de Persistance et de transaction propagation se produisent habituellement ensemble, mais ce n'est pas toujours attention. Par exemple, stateful session beans peuvent avoir un contexte de persistance étendue.