Skip to main content

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

  • From: Werner Keil <werner.keil@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: question regarding JPA-JTA interaction (again)
  • Date: Tue, 19 Jun 2012 07:39:51 +0200

Thanks a lot for that.
I may also participate in JTA MR or at least point Mitch, Spec Lead of JSR 350 (State Management) onto that.
350 while it may or may not become part of the EE 7 release train has some relevant connections with both JPA and JTA.

Unless already EG members, I encourage those heavily interested in transactional matters to at least observe 350, too;-)

Werner
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.



Linda DeMichiel <linda.demichiel@...> schrieb:
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@... <mailto:cromberg@...>> 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@... <mailto:eireland@...>> 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@... <mailto:cromberg@...>]
> > Sent: Friday, 15 June 2012 3:38 a.m.
> > To: jsr338-experts@... <mailto:jsr338-experts@...>
> > 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 cont ext 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@... <mailto:cromberg@...>
> > 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@... <mailto:cromberg@...>
> 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. Regist ered 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@... <mailto:cromberg@...>
> 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.
>
>
>


[jsr338-experts] question regarding JPA-JTA interaction (again)

Christian Romberg 06/14/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Evan Ireland 06/14/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Christian Romberg 06/15/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Christian Romberg 06/15/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Werner Keil 06/15/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

michael keith 06/18/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Christian Romberg 06/19/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Linda DeMichiel 06/18/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Werner Keil 06/19/2012

[jsr338-experts] Re: question regarding JPA-JTA interaction (again)

Christian Romberg 06/19/2012
 
 
Close
loading
Please Confirm
Close