[JTA_SPEC-3] Define timing of delist/end in relation to beforeCompletion Created: 20/Aug/12 Updated: 23/Aug/13 Resolved: 23/Aug/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
See http://java.net/projects/jpa-spec/lists/users/archive/2012-06/message/27 for original detail. In short, define
Also I have not found out yet, whether there are scenarios, where the container must not delist the XAResource. (Although not
If both is defined, i.e. container does not delist XAResource it keeps in it's invocation context before calling Transaction.commit() and
|Comment by irobins [ 30/Sep/12 ]|
Some aspects of the JTA spec were written a while before the container and other subsystem transaction contracts (and certainly before the JCA spec which formalized the managed connection contract) and there are places where the JTA spec appears overly-prescriptive in its assumptions on the implementation details of a container. delistResource is an example of this and may be assuming that containers typically multiplex resources across multiple transactions, which would then put a burden on the container to ensure that the resource was only ever associated with a single transaction at a time through appropriate use of enlist/delist. (Which a container is at liberty to do.) On the other hand, a perfectly normal container implementation strategy is to pool connections (and their resources) keyed off the transaction so that, once associated with a transaction, they remain associated until the transaction ends. In this case the container should never be REQUIRED to delist anything and should be able to rely on the TM to flow XAResource.end(flags) immediately prior to 2PC (after beforeCompletion) without any explicit prompt from the container (beyond initiating transaction completion).
A clarification that would work for me would be to state that:
I would view this as a clarification rather than a change to JTA - this is what WebSphere does and it is compliant today.
Ian Robinson, IBM.
|Comment by paul_parkinson [ 23/Aug/13 ]|
in JTA 1.2 spec and implemented in RI