[cdi-dev] TransactionScope proposal

[Jonathan Halliday]

As requested, some input from a transactions person...


>>>> The transaction context is provided by a built-in context object for the built-in scope type @TransactionScoped. The transaction scope is active when TransactionManager.begin is called (when the status goes to active), and ends when TransactionManager.commit or TransactionManager.rollback is called.

I assume you're making the simplifying assumption that
TransactionManager.suspend and TransactionManager.resume are off limits.

>>>> The transaction context is shared between all beans involved in the transaction. The transaction context is destroyed when transaction is rolledback, or committed.

Interesting things happen when a transaction hits timeout. The tx is (at 
least in the case of JBossTS) rolled back on a background thread, but 
the context on the 'business logic' thread running the tx is still
valid. That is to say, the context destruction is not necessarily
synchronous with the rollback. Unless you specify that it must be, in
which case you have fun issues with requiring that all code be
interruptible.

>>>> Design Notes: CDI transaction context could work with JTA by registering with a Synchronization callback with the Transaction object in JTA.  Then CDI will listen for the STATUS_ACTIVE state to indicate a
transaction is active,

No such notification is generated by the JTA for Synchronizations.
You'll have to wrap TransactionManager.begin to generate that.

>  STATUS_ROLLEDBACK to be notified of a rollback and lastly STATUS_COMMITTED to be notified of a commit.

Those are not the only valid terminal states for a transaction. You may
want to take account of heuristics too.

> The contextual instances will be stored directly or indirectly in the TransactionSynchronizationRegistry when STATUS_ACTIVE is handled, and removed when the STATUS_ROLLEDBACK or STATUS_COMMITTED is handled.

afterCompletion Synchronization calls are exactly that: *after*
Completion. There is no defined transaction context on the Thread any
longer at that point, so no access to TSR.[get|put]Resource.  On the up
side, you don't explicitly need to clean up values stored via
TSR.putResource - once the tx object is garbage collected the store
associated with it goes away too.


Jonathan.


-- 
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)