Hey all,
I am currently checking Spring Forums and StackOverflow to get a definitive answer on what Spring's @Transactional behavior should be in the following situation.
I have two services, Service A and Service B, they look like this:
Additional Info: I use a JpaTransactionManager together with EclipseLink 2.2 inside a Spring 3.1 container with a PostgresQL 9.1 database.
The behavior I see in my code is that the transaction that is started in ServiceA.methodA() is set to rollbackOnly when a RuntimeException occurs in ServiceB.methodB(), even though it is explicitly set to not cause a rollback. From my understanding this seems reasonable because the transaction boundary (ServiceA.methodA()) defines the rollback-behavior and I don't expect this to change for some intermediate calls once the transaction is defined. But... this post at StackOverflow states it to be otherwise: http://stackoverflow.com/questions/6...s-in-submethod
So, is the behavior I see correct, is it a bug in my setup or a change in behavior between Spring 2.5 and 3.1?
Thanks for the clarification
Sven
I am currently checking Spring Forums and StackOverflow to get a definitive answer on what Spring's @Transactional behavior should be in the following situation.
I have two services, Service A and Service B, they look like this:
Code:
class ServiceA {
private ServiceB serviceB;
@Transactional
public void methodA() {
try {
serviceB.methodB();
}
catch (RuntimeException e) {
}
}
}
class ServiceB {
@Transactional(noRollbackFor=RuntimeException.class)
public void methodB() {
// do stuff
}
}The behavior I see in my code is that the transaction that is started in ServiceA.methodA() is set to rollbackOnly when a RuntimeException occurs in ServiceB.methodB(), even though it is explicitly set to not cause a rollback. From my understanding this seems reasonable because the transaction boundary (ServiceA.methodA()) defines the rollback-behavior and I don't expect this to change for some intermediate calls once the transaction is defined. But... this post at StackOverflow states it to be otherwise: http://stackoverflow.com/questions/6...s-in-submethod
So, is the behavior I see correct, is it a bug in my setup or a change in behavior between Spring 2.5 and 3.1?
Thanks for the clarification
Sven