Hi Jonathan,
On Thu, Jun 21, 2012 at 10:21 AM, Jonathan Halliday <
jonathan.halliday_at_redhat.com> wrote:
>
>
> On 06/21/2012 08:33 AM, Christian Romberg wrote:
>
>
>> What should _not_ happen is:
>> 1. That it is an illegal state, that res1.end(xid1) was not called, when
>> txn.commit() is called
>>
>>
> The JTA spec is basically a Java language mapping of the XA spec and,
> although it's not explicit in the JTA spec, it's accepted practice that the
> two documents should be read together. I'd argue the condition you describe
> is covered by table 6-4 in the XA spec, which shows prepare and commit are
> not valid in the active state i.e. you have to call end to transition from
> active to idle before terminating the tx. The wording in XA is also quite
> explicit on this point:
>
> "Before a TM can call xa_prepare () for a transaction branch, all
> associations must be completely ended with xa_end()"
>
> and of the xa_prepare call:
>
> "All associations for *xid must have been ended by using xa_end() with
> TMSUCCESS set in flags"
>
> So an XAResource.prepare is within its rights to (and arguably must)
> generate XAER_PROTO if called before an end call.
>
> The situation with rollbacks is a little more ambiguous as the xa_rollback
> spec does not contain similar wording.
>
It is indeed defined, that from the perspective of an XAResource, it is not
permitted to call prepare(xid1) while this XAResource is still active
with xid1.
However it is undefined by the spec, what Transaction.commit() does. My
requirement is, to clarify the behavior of Transaction.commit() here.
It is neither mandated nor forbidden for the Transaction.commit()
implementation, to call end(xid1,TMSUCCESS) for XAResources, which
are still active (xid1 to be assumed a branch of our to-be-committed
transaction here)
I think this needs clarification, and the JTA spec is the right spec for
that (I did indeed read the XA spec in parallel, and did not find it there
either)
>
> 2. That "beforeCompletion()" is fired _after_ res1.end(xid1) was called
>>
>
> Hmm, I think rather it's the case that, at the time beforeCompletion is
> executed, the XAResource must be associated. It's valid for end(suspend) to
> be called prior to that, provided start(resume) has also been called. What
> you're really trying to achieve is that the Connection behaves as enlisted
> in the tx. IMO that's covered by a combination of provisions in the JTA and
> JCA specs, albeit somewhat tenuously.
>
> "This [beforeCompletion] call is executed with the transaction context of
> the transaction that is being committed." - JTA 1.1 page 33. That is, the
> spec assures that calling getConnection() from a beforeCompletion gives you
> an appropriately enlisted Connection.
>
This does not imply, that all connections are enlisted. This only defines,
that the current thread is bound to the Transaction which is about to be
committed.
It is perfectly valid by the wording at this point, that all XAResources
have already been "ended()".
Also in the example control flow (page 28/29 of JTA spec), the association
has ended.
I agree, that this _should_ also define, that all such Connections are
enlisted, however, this needs clarification as well.
>
> As for cached connection, most JCAs will also guarantee that a previously
> obtained and cached connection will function correctly in such cases, but
> that's really a JCA matter. It hinges on: is the Synchronization considered
> an application component (per JCA 1.5 s2.1.8) for the purposes of JCA
> s7.14.2:
>
> "Irrespective of how a transaction is started, an application server
> enlists all connections (cached or newly acquired by an application
> component) with the transaction, so that the work done using those
> connections will be part of the transaction. This enlistment happens before
> the method call in the case of cached connections and during the method
> call when connections are newly acquired within the transaction"
>
> This could arguably use some clarification, though IMO it belong in the
> JCA rather than JTA spec.
>
I think there is a lot of things which need to be clarified in JCA. We've
made our share of experience with JCA, well, actually the container-side
implementations
of JCA, when providing J2EE support for our JDO implementations.
We are very glad, that with JPA, JCA is no longer of any concern for us.
So I feel a bit uneasy, if anything of the container interaction between
JPA and JTA is defined in an "unrelated" spec.
I think, all clarifications needed do stricly belong in one of (or multiple
of): JPA, JTA and ejb-core.
>
> As a practical matter I think you'll find most transaction manager
> implementers are pretty pragmatic and accustomed to tackling ambiguities in
> the spec in a way that produces fewest surprises for users of their
> software. Certainly as a former JBossTS dev lead I'd consider the behaviour
> you describe to be the expectation of users and the intent of the spec,
> despite the lack of explicit wording for it.
>
> If you have trouble with a transaction manager not behaving in the
> expected way I'd approach its authors first, as you've probably found a bug
> they are happy to fix. Refining the spec is a worthwhile but endless
> process. Fortunately we can mostly get along with an imperfect one.
>
>
It's good to know that, and actually we (Versant) are in a more comfortable
situation, as we have close control over our XAResource, because we provide
the JPA and XAResource implementation together, so we already implemented
the workaround, that XAResource.end(xid,TMSUCCESS) calls a registered
callback, which triggers the flush() operation of the respective entity
manager, instead of triggering this in beforeCompletion().
The reason why I brought this topic up, is not, that we currently
experience any difficulties with any particular implementation,
well, except our mock implementation for testing, which more strictly
follows the spec.
I brought this up because I don't like to layer the definition of the
JPA-JTA interaction on some undefined behavior below that.
Regards,
Christian
--
Christian Romberg
Chief Engineer | Versant GmbH
(T) +49 40 60990-0
(F) +49 40 60990-113
(E) cromberg_at_versant.com
www.versant.com<http://www.google.com/url?q=http%3A%2F%2Fwww.versant.com%2F&sa=D&sntz=1&usg=AFrqEzeeEBc_gN_8mxtt8xDB0tjXDXQVlw>|
www.db4o.com<http://www.google.com/url?q=http%3A%2F%2Fwww.db4o.com%2F&sa=D&sntz=1&usg=AFrqEzdo3Q40RwKQPBtnPIuBYQd1diFxJQ>
--
Versant
GmbH is incorporated in Germany. Company registration number: HRB
54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
CONFIDENTIALITY
NOTICE: This e-mail message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential or
proprietary information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
immediately contact the sender by reply e-mail and destroy all copies of
the original message.