Chris,
While that one's still ramping up, please note, there's another spec coming up with relations to both JTA and JPA.
JSR 350 - State Management. Check it out, if you can, there are heavy aspects like Transactions there, too.
Werner
-------- Original-Nachricht --------
> Datum: Fri, 15 Jun 2012 15:56:55 +0200
> Von: Christian Romberg <cromberg_at_versant.com>
> An: jsr338-experts_at_jpa-spec.java.net
> CC: eireland_at_sybase.com
> Betreff: [jsr338-experts] Re: question regarding JPA-JTA interaction (again)
> 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.
>
> 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.
>
> Christian
>
> On Fri, Jun 15, 2012 at 2:46 PM, Christian Romberg
> <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>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]
> >> > 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.
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
> > --
> > 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.
> >
> >
> >
> >
>
>
> --
> 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.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de