Hi Jonathan,
my requirement was not targeting on disallowing the scenario res2.end(xid2)
after res1.prepare(xid2).
Maybe I simplified my description to much, I did not explicitly mention,
that I described the call sequences
with the same xid in mind - sorry for that!
To clarify, this is the sequence I'm referring to:
txn.registerSynchronization(sync1) //alternatively via
TransactionSynchronizationRegistry; can be done before or after obtaining
the JDBC connection
Connection con = datasource.getConnection(); //the "datasource" is a
container implemented wrapper around an instance of XADataSource that in
turn is implemented by an XA-capable JDBC driver
//the datasource is looked up by JNDI, the name is passed to the JPA
implementation via "jta-data-source"
//this call is done by the JPA implementation
txn.enlistResource(res1); //triggered by the JPA implementation
acquiring a JDBC connection through it's datasource; the container calls
XAConnection.getXAResource and enlists the result
res1.start(xid1, TMNOFLAGS); //called by "enlistResource"
txn.commit(); //called by container, it is not
currently required - or forbidden - that the container delists res1 (this
was one of the other conditions I talked about)
Now for my specific requirement, what should happen in txn.commit(), to
make the JPA-JTA interaction work:
(and probably this is already happening in all real-life implementations,
but to my knowledge not a specified behavior)
sync1.beforeCompletion(); //this will flush all pending changes
through "con" which is still in the context of "xid1"
res1.end(xid1, TMSUCCESS);
res1.prepare(xid1);
res1.commit(xid1);
What should _not_ happen is:
1. That it is an illegal state, that res1.end(xid1) was not called, when
txn.commit() is called
2. That "beforeCompletion()" is fired _after_ res1.end(xid1) was called
Sorry for the confusion of my first description, it was simply not precise
enough
Regards,
Christian
On Wed, Jun 20, 2012 at 5:10 PM, Jonathan Halliday <
jonathan.halliday_at_redhat.com> wrote:
>
> On 06/20/2012 11:01 AM, Christian Romberg wrote:
>
> condition A3. Transaction.commit() must execute the following in this
>> order:
>>
> ...
>
> -implicit ending of XAResources, that have not been ended yet
>> -do all the prepare calls
>>
>
> I don't agree with that one. It's valid for the TM to process XAResources
> in parallel, provided that for any given resource the {end,prepare}
> ordering is serial. res2.end may come after res1.prepare. Both end and
> prepare may be remote calls, so it's important from a performance
> perspective to be able to handle the set of XAResources concurrently as
> much as possible. Why do you require that a given branch is ended before
> some other branch is prepared?
>
> Jonathan.
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
> (USA), Charlie Peters (USA)
>
--
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.