In first case study given at http://www.vermatech.com/code/SpringTransactionExamples.html,
program is calling two methods i.e.
testModel.deleteAllCountries();
testModel.initializeCountries();
where initializeCountries throws runtime exception. For both methods' transaction definition attribute is PROPAGATION_REQUIRED. Still transaction under deleteAllCountries
method gets committed but transaction under initializeCountries are rolled back(as per the logs given in the same case study).
As per PROPAGATION_REQUIRED definition is that it Support a current transaction; create a new one if none exists. So my question here is transaction under initializeCountries method
should support the transaction under deleteAllCountries method. I mean both method should be treated as single transaction. As per my understanding either complete transaction should be committed or rolled back? Not sure how come logs are treating them separately.
"Propagation required" is defined as
Support a current transaction, create a new one if none exists.
In your case above the deleteAllCountries method executes in a transaction and commits. There is no current transaction when initializeCountries is called, so it executes in a second transaction, and rolling it back has no effect on the changes made by the first method.
Propagation applies to nested method calls, not to successive ones. If you look at the documentation:
When the propagation setting is PROPAGATION_REQUIRED, a logical
transaction scope is created for each method upon which the setting is
applied. Each such logical transaction scope can determine
rollback-only status individually, with an outer transaction scope
being logically independent from the inner transaction scope. Of
course, in case of standard PROPAGATION_REQUIRED behavior, all these
scopes will be mapped to the same physical transaction. So a
rollback-only marker set in the inner transaction scope does affect
the outer transaction's chance to actually commit (as you would expect
it to).
However, in the case where an inner transaction scope sets the
rollback-only marker, the outer transaction has not decided on the
rollback itself, and so the rollback (silently triggered by the inner
transaction scope) is unexpected. A corresponding
UnexpectedRollbackException is thrown at that point. This is expected
behavior so that the caller of a transaction can never be misled to
assume that a commit was performed when it really was not. So if an
inner transaction (of which the outer caller is not aware) silently
marks a transaction as rollback-only, the outer caller still calls
commit. The outer caller needs to receive an
UnexpectedRollbackException to indicate clearly that a rollback was
performed instead.
then you can see all of this is about inner- and outer-, none of it mentions successive calls. In your case the call to deleteAllCountries is the outermost transactional method, so when it finishes successfully then Spring commits the transaction immediately. Then your call to initializeCountries has to be executed within a separate transaction, where it is the outermost method.
Your assumption seems to be that Spring will hold the transaction open after the first method finishes, but that's not how it works. In order to get the effect you want, you could create another method on testModel that wraps the calls to deleteAllCountries and initializeCountries, make that method transactional and give it the attribute PROPAGATION_REQUIRED. That way a rollback of the second method will cause the first method's changes to be rolled back too, because the wrapping method is grouping them together. Otherwise nothing is telling Spring these things should be part of the same transaction.
Related
According to documentation, in container managed transactions, if a method is annotated with TransactionAttributeType.REQUIRES_NEW attribute, will suspend any client transaction, delegate the call to this method/ create a new transaction, and resume to previous transactions after the new one has been completed.
So this actually means, that no new thread is created, and that the previous transaction is on a "wait" state until the new one is has been finished?
As stated in the Java-Doc:
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.
It's not abandoning the thread or creating a new one, it's only releasing the association to the transaction and recreating it afterwards. If it would create a new thread, there would be no need to remove the association because it was never made.
Container managed transactions means JTA and JTA specifications does not allow transactions to span across multiple threads. Each JTA transaction is associated with an execution thread, so it means that at most one transaction can be active at any given time. Note that multiple transactions can be associated with a single thread, but again only one can ever be active at a given time.
As JTA does not support nested transactions, it means that if one transaction is active, it is not possible to start another one in the same thread, until the first transaction commits or rolled back (or timed out, causing again rollback), thus releasing transaction association with the current thread.
What happens behind the scenes when method with transactional attribute REQUIRES_NEW is called with the transactional context? First, JTA temporarily suspends the transaction that is currently associated with the calling thread by calling it is internal API, particularly it calls TransactionManager.suspend(). (If calling thread is not associated with any transaction (i.e. method was called with transactional attribute of NOT_SUPPORTED or without transactional context) a null object reference is returned) and obtaining Transaction object. This Transaction object will be passed to TransactionManager.resume() method to re-associate the transaction context with the calling thread once above mentioned REQUIRES_NEW method completes. Whether on same or another thread depends on JTA implementation, as specification does explicitly require it to be one way or the other.
Answering your question - the only way for JTA to fulfill transactional attribute REQUIRES_NEW when called in transactional context is to suspend the transaction from a thread and resume it later on the same or another thread. When it will be resumed? Remember that REQUIRES_NEW attribute basically means is that annotated method always have to be in its OWN TRANSACTION, which in turn means that the method should be committed or rolled back independently of methods further up the call stack. Suspended transaction will be resumed, once called method with transactional attribute REQUIRES_NEW commits or rolled back.
As a side notes, as you may probably know, there is no way for Bean Managed Transaction to suspend a transaction, you can't do it programatically. Only JTA can do this using an it's internal transaction management API and you can achieve this declaratively by using CMT and transaction attributes. Also note that this attribute can lead to excessive transaction overheads is overused.
I would like to ask question regarding EJB. I am using eclipselink of JPA.
There is two stateless objects in a stateless object in my code.
Is that possible this two stateless object use two different transactions?
Absolutely. You may find it useful to read about the transaction attributes.
If the called method in your first class (say StatelessFirst) has a transaction type REQUIRED (the default) or REQUIRES_NEW, when it is called it will initiate a new transaction. If this then calls a method in your second class (say StatelessSecond) with transaction type REQUIRES_NEW, the first transaction is suspended and a second transaction is initiated while the second method executes. When the method in StatelessSecond completes, the second transaction commits, the first transaction is reinstated, and control is passed back to StatelessFirst.
To make the first transaction commit before StatelessSecond is called, you can use bean-managed transactions. This gives you full control over the transaction management, so in StatelessFirst you can begin a transaction, then commit then call StatelessSecond. If you go with this approach, note that you can't perform nested transactions in BMT.
One other option which allows you to stay within CMT would be to pull the transactional behaviour out of StatelessFirst into a third EJB, with REQUIRES_NEW. Then the pattern is:
Client calls StatelessFirst, which initiates transaction A
StatelessFirst calls NewBean, which initiates transaction B, and performs some work
NewBean commits transaction B and returns
StatelessFirst calls StatelessSecond, which initiates transaction C, and performs its work
StatelessSecond commits transaction C and returns
StatelessFirst completes, and commits transaction A (which doesn't have any changes anyway)
In Spring, if I have:
ServiceA.serviceA() -> ServiceB.serviceB() -> ServiceC.serviceC() ->ServiceD.serviceD()
where ServiceD.serviceD() can throw a runtime exception: MyRuntimeException, which is propagated back up to ServiceA.serviceA catch block. Does it matter on which service I put #Transactional(noRollbackFor=[MyRuntimeException.class]) on?
Is there any difference between putting it on any of the services?
Note: All my Services are marked as #Transactional
As you did not give precision on that, I assume that you are using default propagation of PROPAGATION_REQUIRED. In that context, the 4 services will use the same transaction, and if any of the three inner marks the transaction as read-only as a result of the exception, the outer will get a UnexpectedRollbackException to inform it that the asked commit actually resulted in a rollback. From Spring Reference Manual : However, in the case where an inner transaction scope sets the rollback-only marker, the outer transaction has not decided on the rollback itself, and so the rollback (silently triggered by the inner transaction scope) is unexpected. A corresponding UnexpectedRollbackException is thrown at that point. This is expected behavior so that the caller of a transaction can never be misled to assume that a commit was performed when it really was not. So if an inner transaction (of which the outer caller is not aware) silently marks a transaction as rollback-only, the outer caller still calls commit. The outer caller needs to receive an UnexpectedRollbackException to indicate clearly that a rollback was performed instead.. And if the outer transaction decides to rollback the transaction because of the exception, the transaction will obviously be rolled back.
So if none of the services catches the exception, and if you use a propagation of PROPAGATION_REQUIRED, at least the four involved methods have to be annotated with #Transactional(noRollbackFor=[MyRuntimeException.class]).
An alternative of using noRollbackFor=[MyRuntimeException.class] would be to catch the exception in the appropriate method of ServiceD. In that case, the exception will never climb up the stack, and none of the transactional proxies will ever knows it occurred. The commit would then normally happen at the end of the transaction.
Edit per comment :
If you want further control on exception management, you could try to duplicate method : a transactional method, that calls a non transactional one in your service class. And you could call the non-transactional one if you do not want another transactional proxy in the chain. But this has sense only if this use case (a service class calling another service class with special exception requirement) is exceptional.
As an alternative, you could inject the implementations on the other service classes instead of injecting the transactional proxies (#Autowired private ServiceBImpl serviceB;). As you are already have a transaction obtained at the outer level, all DAO operations should be fine, and as there is only one transactional proxy at the outer level, you have one single point of control for exception management. It is rather uncommon to inject classes instead of interfaces, and you should document the why in a red flashing font :-) , but it should meet your requirements.
If you use a combination of
#Transactional(propagation = REQUIRES_NEW, noRollbackFor = MyRuntimeException.class)
then this service can commit independently from the rollback of the parent transaction (which will occur if it is not annotated with noRollbackFor). Otherwise you would have to mark all the transactional methods involved with the same noRollbackFor annotation.
I can't understand the behavior difference between the PROPAGATION_REQUIRES_NEW and PROPAGATION_NESTED propagation policies. It seems to me that in both cases, the current process is rollbacked but not the whole transaction. Any clue?
See this link: PROPAGATION_NESTED versus PROPAGATION_REQUIRES_NEW? Juergen Hoeller explain it very well. -- the Spring Source Forum is completely offline since February 28, 2019, but you can read the relevant part of the article in the quote below
PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction
for the given scope. This transaction will be committed or rolled back
completely independent from the outer transaction, having its own
isolation scope, its own set of locks, etc. The outer transaction will
get suspended at the beginning of the inner one, and resumed once the
inner one has completed. ...
PROPAGATION_NESTED on the other hand starts a "nested" transaction,
which is a true subtransaction of the existing one. What will happen
is that a savepoint will be taken at the start of the nested
transaction. Íf the nested transaction fails, we will roll back to
that savepoint. The nested transaction is part of of the outer
transaction, so it will only be committed at the end of of the outer
transaction. ...
PROPAGATION_REQUIRES_NEW : uses a completely independent transaction for each affected transaction scope. In that case, the underlying physical transactions are different and hence can commit or roll back independently, with an outer transaction not affected by an inner transaction's rollback status.
PROPAGATION_NESTED : uses a single physical transaction with multiple savepoints that it can roll back to. Such partial rollbacks allow an inner transaction scope to trigger a rollback for its scope, with the outer transaction being able to continue the physical transaction despite some operations having been rolled back. This setting is typically mapped onto JDBC savepoints, so will only work with JDBC resource transactions.
check spring documentation
Please find the difference
1.) Use of NESTED Transaction
Execute within a nested transaction if a current transaction exists, behave like PROPAGATION_REQUIRED else.
Nested transaction is supporting by Spring
2.)Use of REQUIRED Transaction
Support a current transaction, create a new one if none exists.
. It means for banking domain like withdraw,deposit, update the transaction
3.) Use of REQUIRES_NEW Transaction
Create a new transaction, and suspend the current transaction if one exists.
I am using annotation based declarative approach for spring aop.
sample code
ClassA{
#Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
add()
{
method1();
method2();
method3();
}
}
But I have still doubt on use of propagation.does propagation.Requires_New means that each request will start new transaction.
Second question:
Does failure of any method like method2,method3 will cause the transaction to rollback?
I will be very happy if any can help me to leans transaction propagation.
can someone provide me a real world example where we need a participate in existing transaction.because I visualise that add function that we are using in above example will be independent for all users,or any other function will be independent to each user who is calling. I am not able to find example where other propagation behaviour like PROPAGATION_SUPPORTS ,PROPAGATION_MANDATORY,PROPAGATION_REQUIRES_NEW etc. are used
Answering this comment, not the actual question:
transaction are session specific or
request specific – Vish 3 hours ago
Neither. request and session are both web-specific scopes, while the Spring Transaction abstraction has nothing to do with web technologies.
The scope of #Transactional is per method invocation, as #Transactional is implemented through Spring AOP. The transactional state is kept in ThreadLocal variables which are initialized when the outermost #Transactional method is entered and cleared with commit or rollback when it is left. This whole abstraction works on Java method level, and hence does not require or profit from a web container.
And in response to this Question in the comment below:
thanks #sean,i am stil not able to get
answer where other propagation
behaviour like PROPAGATION_SUPPORTS
,PROPAGATION_MANDATORY,PROPAGATION_REQUIRES_NEW
etc are used. please refer above for
whole question
Here's the list of Propagation values with my comments:
MANDATORY
Support a current transaction, throw an exception if
none exists.
Does not start a new Transaction, just checks whether a transaction is active (must be inside either another #Transactional method call or a programmatically created transaction)
NESTED
Execute within a nested transaction if a current transaction
exists, behave like
PROPAGATION_REQUIRED else.
Start a nested transaction if a transaction exists, start a new transaction otherwise.
NEVER
Execute non-transactionally, throw an exception if a transaction
exists.
Does not start a transaction. Fails if a transaction is present.
NOT_SUPPORTED
Execute non-transactionally, suspend the current transaction if one
exists.
Does not start a transaction. Suspends any existing transaction.
REQUIRED
Support a current transaction, create a new one if none
exists.
If a transaction exists, use that, if not, create a new one. In 95% of cases, this is what you need.
REQUIRES_NEW
Create a new transaction, suspend the current transaction if one
exists.
Always creates a new transaction, no matter if an existing transaction is present. If there is, it will be suspended for the duration of this method execution.
SUPPORTS
Support a current transaction, execute
non-transactionally if none exists.
Can use a transaction if one is present, but doesn't need one (and won't start a new one either)
In most cases, REQUIRED is what you need (hence it's the default in the #Transactional annotation). I have personally never seen any other value but REQUIRED and REQUIRES_NEW in use.
Transaction propagation indicates what should be the behaviour of the given method when it is invoked. REQUIRES_NEW means that a new transaction should always be started, even if there is an ongoing transaction.
If method1(), for example, defines REQUIRES_NEW, than it will execute in a new transaction.
An exception will rollback the current active transaction, yes.
Yes. Requires_New means that each request will start new transaction. and Yes failure in method2,method3 will cause the transaction to rollback, depending on the rollback properties.
check Transactional properties.