[JTA_SPEC-3] Define timing of delist/end in relation to beforeCompletion Created: 20/Aug/12  Updated: 23/Aug/13  Resolved: 23/Aug/13

Status: Closed
Project: jta-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: paul_parkinson Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See http://java.net/projects/jpa-spec/lists/users/archive/2012-06/message/27 for original detail. In short, define
"
However so far I have been unsuccessful to find out, whether it is portable behavior, for the container to call Transaction.commit() while
there are any XAResource enlisted with this Transaction, where start() had been invoked, but end() has not.

Also I have not found out yet, whether there are scenarios, where the container must not delist the XAResource. (Although not
directly applicable, the control flow diagram p.28/29 in the JTA spec suggests otherwise.)

If both is defined, i.e. container does not delist XAResource it keeps in it's invocation context before calling Transaction.commit() and
Transaction.commit() handles still enlisted resources fine (by calling beforeCompletion() first, calling end() after that, and then prepare+commit)
then we (i.e. the JPA spec) would not have a problem.
"
or allow that the current specification of "beforeCompletion callback methods can access the resources, but that no transactional work can be performed on resources in afterCompletion" is sufficient.



 Comments   
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:
a container only need to drive delistResource to explicitly dissociate a resource from a transaction, if a container needs to do this (and some will not); it should not be interpreted as a mandatory container requirement as a preCondition to transaction completion
(ii) a TM should be required to implicitly end the association of any associated XAResource immediately prior to completion (i.e before prepare or commit/rollback in the onephase-optimized case).

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

Generated at Sat Mar 28 04:46:00 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.