-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
None
-
None
CachedConnectionManager lazy transaction enlistment doesn't work correctly with nested transaction. The problem was discovered when transactions were managed by spring framework, but in general correct usage of UserTransaction APImay lead to incorrect behavior that can compromise data integrity. The scenario can be shown on a following example:
void outer { //1 foo(); //7 showLog(); } @Transactional(REQUIRED) Foo foo { //2 log("BEGIN"); //3 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); //4 Foo foo = em.find(Foo.class, id); //5 log("END"); //6 showLog(); return foo; } @Transactional(REQUIRES_NEW) void log(String a) { //adds a logged string into database (...) } void showLog(){ //prints log entries from the database (...) }
In 1 invocation of a foo method leads to creation of a transaction A but no connection is yet created so nothing is added to CachedConnectionManager records. In 2 new transaction B is created and transactionStarted notification is performed but since there is nothing in CCM records it has no result. The transaction finishes successfully. In 3 we are marking transaction A as rollback only. In 4 database search results in connection creation. The connection is added to CCM. In 5 new transaction C is created but this time record created in point 3 is present in CCM records so it is enlisted in transaction C (BUG). In 6 log shows both BEGIN and END records. In 7 after transaction A rollback only record "BEGIN" is present in the database.
- causes
-
JBEAP-27263 [GSS](8.0.z) A Transaction (B) with propagation REQUIRES_NEW should be able to write to database, even though a surrounding transaction (A) has been marked for rollbackOnly.
- New
- is related to
-
JBJCA-1494 CachedConnectionManager refactor
- Open