Christian,
In your step 6:
"when the method invocation (of e.g. a session bean) ends, the container
will call Transaction.delistResource()"
I wonder if that is the root of the difficulty.
If the TM keeps JDBC connections (and/or XA resources) enlisted (in case
they are reused later in the same TX) until just before step 7b, then the
issue you are concerned about will not occur.
> -----Original Message-----
> From: Christian Romberg [mailto:cromberg_at_versant.com]
> Sent: Friday, 15 June 2012 3:38 a.m.
> To: jsr338-experts_at_jpa-spec.java.net
> Subject: [jsr338-experts] question regarding JPA-JTA
> interaction (again)
>
> Dear group,
>
> While investigating and implementing our JTA integration, I
> came across the following problem for the standard
> implementation approach:
>
> 1. container starts a JTA transaction
> 2. createEntityManager is called, and registers a
> Synchronization instance
> 3. as soon as the EntityManager acquires a JDBC connection,
> the container gets the XAConnection from the connection pool,
> passes the result of XAConnection.getConnection() to the
> EntityManager and registers the result of XAConnection.getXAResource()
> with the current JTA transaction
> 4. the TM calls XAResource.start(xid, TMNOFLAGS);
> 5. all work done by the EntityManager with that connection
> happens in the context of the transaction (branch) denoted by xid now
> 6. when the method invocation (of e.g. a session bean) ends,
> the container will call Transaction.delistResource() which in
> turn will
> call XAResource.end(xid, TMSUCCESS) [mandated by JTA spec,
> JTA 1.1 sequence diagram on page 29]
> 7. Transaction.commit() will drive the
> 2-phase-commit-protocol, before invoking prepare and commit,
> all "beforeCompletion()" calls
> of registered Synchronization instances are invoked
> 7a. the beforeCompletion() implementation of the
> Synchronization instance registered in step 2 is supposed to
> flush all changes to the database
> 7b. XAResource.prepare(xid) is invoked
> 7c. XAResource.commit(xid) is invoked
>
> The problem ist step 7a: The connection is not associated
> with xid, so this simply does not work.
> Even if the connection is lazily acquired and released, there
> is no portable way to trigger the necessary
> start() and end() invocations by the JPA implementations.
>
> So how is this supposed to work?
>
> (Btw. we have direct control over our XAResource
> implementation, so we can trigger flushing by having a
> callback from our XAResource to
> our EntityManager during XAResource.end(), but this naturally
> is not an option, if a 3rd-party XAResource implementation is used.)
>
> 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&s
> a=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.
>
>
>
>
>