Atomikos Forum

Hi

We recently moved from websphere application server to a standalone spring jms atomikos architecture.

With websphere, if a transaction reach the max timeout, the transaction’s thread is interrupted by the transactionManager.

I'm not 100% sure but with atomikos, it looks like the transactionManager marks the thread for setRollBackOnly just after the timeout
But the thread is still working running.

Is it the normal behavior of Atomikos transaction manager ?

Just add some logs to highlight the problem

// ATOMIKOS

//I'll put the max timeout to 10s
Slf4jConsole: 107 - Attempt to create a transaction with a timeout that exceeds com.atomikos.icatch.max_timeout - truncating to: 10000

// Do something in a loop
18:15:06,724 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 7
18:15:51,563 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 8
18:15:55,010 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 9

//setRollbackOnly
18:16:01,672  INFO Atomikos:2                  Slf4jConsole: 110 - setRollbackOnly() called for transaction ${mdp.atomikosTmUniqueName}0001100001

// nothing change in the process
18:16:01,673 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 10
18:16:02,673 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 11
18:16:03,673 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 12


// The expected logs  would be :
// Do something in a loop
18:15:06,724 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 7
18:15:51,563 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 8
18:15:55,010 DEBUG      main        AtomikosKillTest$2: 366 - doInTransaction wake up number 9
// ROLLBACK
// END

Hi,

Yes this is normal. Why is it a problem? AFAIK interrupting a thread only works if all libraries that it invokes are well-behaved and interruption-aware...

Guy