jta-spec
  1. jta-spec
  2. JTA_SPEC-3

Define timing of delist/end in relation to beforeCompletion

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      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.

        Activity

        Hide
        irobins added a comment -

        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.

        Show
        irobins added a comment - 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.
        Hide
        paul_parkinson added a comment -

        in JTA 1.2 spec and implemented in RI

        Show
        paul_parkinson added a comment - in JTA 1.2 spec and implemented in RI

          People

          • Assignee:
            Unassigned
            Reporter:
            paul_parkinson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: