[jboss-dev-forums] [JBoss Transactions Development] - Re: Asynchronicity and transaction context propagation

[mark.little@jboss.com]

"chtimi2" wrote : Are you referring to the TrCoreProgrammersGuide pdf? I think so (was probably renamed) but just to be sure. 
  | 

Yes.

anonymous wrote : 
  | As i thought, the check method is passed a list of the active threads. 
  | If i'm not mistaken, i would just need to implement a BlockingCheckedAction, that calls join() on all those threads, and use it for the global transaction.
  | 

That should work.

anonymous wrote : 
  | To sum it up: 
  | 1/ Launch the server with -Dcom.arjuna.ats.jts.checkedTransactions=YES to enable checked transactions
  | 

Last time I checked it was on by default.

anonymous wrote : 
  | 2/ Implement BlockingCheckedAction that does: for (Thread t: list) { t.join() }
  | 3/ Just after the global transaction has started i would need to do 
  | Current current = OTSManager.get_current().
  |   | current.setCheckedAction ( new BlockingCheckedAction() );
  | 
  | 
  | I thought of a simple unit test to verify the correctness of the transactional behaviour. 
  | Do you think this would work? I prefer asking before i start spending time integrating another TransactionManager in Spring.
  | 
  | 1/ UnitTest (UT) calls transactional service void updateXY ( int X , int Y , boolean failOnUpdatingY ) synchronously
  | 2/ The global transaction is initiated and updateXY updates X
  | 3/ updateXY then calls transactional service updateY ( int Y , boolean failOnUpdatingY ) asynchronously 
  | 4/ updateY executes within the same global transaction; if (failOnUpdatingY) a RuntimeException is thrown, which must rollback the global transaction
  | 5/ UT sleeps for a second, by then the transaction should have been committed or rolled back
  | 6/ UT calls getX and getY
  | 7/ Verifications:
  | 		Case ! failOnUpdatingY: X and Y should have their new values because the global transaction has been committed
  | 		Case failOnUpdatingY: X and Y should have their old values because the global transaction has been rolled back
  | 

Assuming you're not looking at distributed invocations here then that looks like it should work (but I haven't put a lot of time into thinking about it.)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256661#4256661

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256661