How does UserTransaction propagate?

Question

I have a stateless bean with bean-managed transactions, and a method like this:

@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();

    }

}

So how does the UserTransaction propagate to the OtherStatelessBeanLocal bean?

Burkey

well it doesnt, right? – Maybellmaybelle

Answer 1

The UserTransaction object is an object supplied by the container which wraps access to API calls that the container uses internally, specifically javax.transaction.TransactionManager. The TransactionManager has methods like begin, commit, rollback and javax.transaction.Transaction getTransaction()

Under the covers, the TransactionManager will use a ThreadLocal or similar technique to track the current transaction state with the thread. ThreadLocals are very simple objects that could easily be described as a static HashMap that uses the thread name as the key and an object of your choosing as the value. As long as you stay in the same thread, you can get the object from any point in the invocation chain. This is one of the reasons it is not allowed to start threads in a Java EE environment.

Security propagation works in a similar way, as do JNDI lookups which magically point to the right module's or component's java:comp/env namespace. Bottom line is you cannot implement an app server without ThreadLocals. Propagation sounds more active than it is, when in truth it is simply the act of not leaving the thread so the container and all involved can still find your "stuff".

Back in transaction management terms, the object that a TransactionManager will track in its ThreadLocal will typically implement (directly or indirectly) both the Transaction and TransactionSynchronizationRegistry interfaces. Between these two interfaces, the container has all the hooks it needs to track DataSources, EntityManagers and other resources in the current transaction on your behalf. These interfaces also allow the container to offer callbacks such as SessionSynchronization, as well as means to do other things on your behalf upon transaction completion such as flushing/closing EntityManagers, sending JMS pending messages, and persisting any Timers created by your app in the course of the transaction.

Humber

Actually not, because it doesn't apply the knowledge to the asked question. – Spriggs

Answer 2

Based on EJB specification, you can not pass a transaction context from a bean (in this case your main class ... ) using programmatic transaction into another bean (in this case, other) using programmatic transaction

Neela

Answer 3

For EJB3 you normally define transaction propagation with the @TransactionAttribute annotation.

The default transaction attribute for all EJB 3.0 applications is REQUIRED:

If a client invokes the enterprise bean's method while the client is associated with a transaction context, the container invokes the enterprise bean's method in the client's transaction context.

The doc's for transaction type are here: http://download.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.html

N.B. Persistence context and transaction propagation typically happen together but not always - beware. For example, stateful session beans may have an extended persistence context.

Ouabain

Note in the case of EXTENDED persistence context, the persistence context is still exclusively associated with the transaction and not available to other transactions by virtue that as soon as the holding @Stateful bean becomes involved in the transaction, it is not allowed to leave the transaction till it commits or rollsback. All requests on that @Stateful bean from outside the transaction will wait for the duration of @AccessTimeout before finally throwing some form of ConcurrentAccessException. – Humber