I understand that when REQUIRES_NEW is specified with @Transacton on a method that the current transaction is suspend and a new one is created. What does suspended mean? Are there still two transactions even though the first is suspended.
Suppose method one has REQUIRES and method two has REQUIRES_NEW. When method one calls method two are there two transactions (one is just suspended) or one transaction?
If you already have a transaction and the annotated method is called, the first one is suspended and a new one begins. In this scenario, there are 2 transactions.
If you don't have a transaction and the annotated method is called, a new one is started. In this scenario, there is only one transaction.
The Javadocs state:
The container must invoke an enterprise bean method whose transaction attribute is set toREQUIRES_NEW with a new transaction context.
If the client invokes the enterprise bean's method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method.
If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before starting the new transaction and invoking the method. The container resumes the suspended transaction association after the method and the new transaction have been completed.
Joined: Mar 23, 2013
Thank James. I thought there would be two transactions.
Joined: Mar 23, 2013
I forgot to add that both the methods are in the same class. In this case there would be only one transaction, correct? This is because of the proxy created by Spring AOP. One method that calls another within the same class will not trigger the advice.
From Spring Reference
Note: In proxy mode (which is the default), only 'external' method calls coming in through the proxy will be intercepted. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with @Transactional!