Pri
Pri

Reputation: 31

How does spring transactions at various levels work?

I have class A and class B as shown in the code. In the code mentioned how will the transaction behave? Inside class B, will it close the transaction after commit because of isolation_level?

Class A{
 @Transactional(propagation = Propagation.REQUIRED)
    method classAMethod(){
       B b = new B();
       b.classBMethod
    }
}

Class B{
@Transactional(propagation = Propagation.REQUIRED,isolation = Isolation.READ_COMMITTED)

  method classAMethod(){
     B b = new B();
     b.classBMethod
  }

}

I am running a batch job, which after some time run into "failed to execute Could not roll back JPA transaction; nested exception is javax.persistence.PersistenceException: unexpected error when rollbacking" exception and I am suspecting that the above kind of code mentioned is causing the problem.

Upvotes: 1

Views: 313

Answers (1)

crizzis
crizzis

Reputation: 10716

Well, the Javadoc for @Transactional.isolation states:

Exclusively designed for use with Propagation.REQUIRED or Propagation.REQUIRES_NEW since it only applies to newly started transactions. Consider switching the "validateExistingTransactions" flag to "true" on your transaction manager if you'd like isolation level declarations to get rejected when participating in an existing transaction with a different isolation level.

while the Javadoc for AbstractPlatformTransactionManager.validateExistingTransactions says that:

When participating in an existing transaction (e.g. with PROPAGATION_REQUIRED or PROPAGATION_SUPPORTS encountering an existing transaction), this outer transaction's characteristics will apply even to the inner transaction scope. Validation will detect incompatible isolation level and read-only settings on the inner transaction definition and reject participation accordingly through throwing a corresponding exception.

Default is "false", leniently ignoring inner transaction settings, simply overriding them with the outer transaction's characteristics. Switch this flag to "true" in order to enforce strict validation.

From the above you can conclude that without validateExistingTransactions set to true, the transaction will simply continue, even if the isolation level is different from the one requested. The 'outer' transaction characteristics take precedence.

Upvotes: 1

Related Questions