Hi Christian, all,
On 6/15/2012 6:56 AM, Christian Romberg wrote:
> Finished my research of the ejb-core (3.0), jta (1.1) and jpa (2.0) specs and found nothing, that guarantees these two
> behaviors.
>
The Connector spec also weighs in on the container / resource manager interaction, but AFAICT does not address
this either.
> So for me it looks like, that we rely on undefined behavior.
>
> I might have overseen something, and if anyone knows more, I would appreciate it, if you let me know.
>
The JTA spec is undergoing a Maintenance Release as part of Java EE 7. I would encourage you to join
the project (which is just getting started) and to file an issue on this topic.
See
http://java.net/projects/jta-spec/. Paul Parkinson, cc'd here, is leading this work.
regards,
-Linda
> Christian
>
> On Fri, Jun 15, 2012 at 2:46 PM, Christian Romberg <cromberg_at_versant.com <mailto:cromberg_at_versant.com>> wrote:
>
> Evan,
>
> You are right, the issue would not occur then.
>
> 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.
>
> If anyone knows, that that is defined somewhere, please let me know, I will also continue researching the related specs.
>
> If that is not explicitly defined, than we (i.e. the JPA spec) do have a problem, because we rely on undefined behavior.
>
> Regards,
>
> Christian
>
>
> On Thu, Jun 14, 2012 at 10:31 PM, Evan Ireland <eireland_at_sybase.com <mailto:eireland_at_sybase.com>> wrote:
>
> 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 <mailto:cromberg_at_versant.com>]
> > Sent: Friday, 15 June 2012 3:38 a.m.
> > To: jsr338-experts_at_jpa-spec.java.net <mailto: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 <tel:%2B49%2040%2060990-0>
> > (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
> > (E) cromberg_at_versant.com <mailto:cromberg_at_versant.com>
> > www.versant.com <http://www.versant.com>
> > <http://www.google.com/url?q=http%3A%2F%2Fwww.versant.com%2F&s
> <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.db4o.com>
> > <http://www.google.com/url?q=http%3A%2F%2Fwww.db4o.com%2F&sa=D
> <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.
> >
> >
> >
> >
> >
>
>
>
>
> --
> Christian Romberg
> Chief Engineer| Versant GmbH
> (T) +49 40 60990-0 <tel:%2B49%2040%2060990-0>
> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
> (E) cromberg_at_versant.com <mailto: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.
>
>
>
>
>
>
> --
> Christian Romberg
> Chief Engineer| Versant GmbH
> (T) +49 40 60990-0
> (F) +49 40 60990-113
> (E) cromberg_at_versant.com <mailto: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.
>
>
>