REQUIRES_NEW at REQUIRES_NEW at REQUIRES_NEW ... incl. And incl.

Question

Jboss 4.x
EJB 3.0

I saw code similar to the following (very shortened):

@Stateless @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) public class EJB1 implements IEJB1 { @EJB private IEJB1 self; @EJB private IEJB2 ejb2; @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public boolean someMethod1() { return someMethod2(); } @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public boolean someMethod2() { return self.someMethod3(); } @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public boolean someMethod3() { return ejb2.someMethod1(); } } 

And let's say that EJB2 is an almost exact copy of EJB1 (the same three methods) and EJB2.someMethod3() calls in EJB3.someMethod1() , which then finally EJB3.someMethod3() to EJB3.someMethod3() in the database.

This is a contrived example, but we saw a similar code given above in our code base. The code really works just fine.

However, this seems like a terrible practice, and I'm worried about @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) for every method that doesn't even execute any database entries. This really creates a new transaction every time for every method call with the result:

new transaction
-required transaction
- New transaction
--- new transaction
... (many more)
------- new transaciton (DB record)

And then it unfolds at that moment? Could this be a reason for performance? Additional thoughts?

Answer 1

This really creates a new transaction every time for every method call.

No, it is not. A new transaction will be created only when the method is called by an EJB link from another bean. Calling method2 from method1 within the same bean will not trigger a new transaction.

See also here and here . The latter is an exceptionally good article explaining transaction management in EJB.

Edit:
Thanks to @korifey for pointing out that method2 actually calls method3 on the bean link, which leads to a new transaction.

Answer 2

It really creates a new JTA transaction in each EJB, and this should have a serious performance effect for read-only methods (which does only SELECTS, not updates). Use @SUPPORTS for read-only methods.