Date: Mon, 14 May 2012 10:11:44 -0700
Christian,
In a JPA environment, a JPA Persistence Unit registers as a transactional
resource to the application server's global transaction management
coordination system via JTA standard i.e. by caling
javax.transation.registerSynchronization(x) where x is something that a
provider provides which implements javax.transaction.Synchronization. In a
non-JDBC JPA provider like yours, you will possibly pass an instance of
persistence context i.e EntityManager as x.
For an application server transaction management sevices, all it knows is x
whether x is using an underlying JDBC or non-JDBC database is not relevant.
So essentially the provider will receive a beforeCompletion() call from
application server when time comes to commit the global transaction via x
because x is a registered Synchronization object. At beforeCompletion(),
the provider is responsible to commit on the underlying database be it JDBC
or somethiing else.
If a provider's persistence unit is also XA-enabled that capability is
communicated by a) implementing javax.transaction.xa.XAResource and b)
enlisting that resource to the application server. A resource, in this
case, is the persistence unit, not the jta-data-source as declared in
persistence.xml.
In effect, I do not see why a non-JDBC based JPA provider has to appear as
a JDBC connection to a application server to participate in a JTA
transaction.
> I think I forgot to emphasize, that we are not an ORM and are not using
JDBC connections.
I did notice that :)
Regards --
Pinaki Poddar
Chair, Apache OpenJPA Project http://openjpa.apache.org/
JPA Expert Group Member
Application & Integration Middleware
From: Christian Romberg <cromberg_at_versant.com>
To: michael keith <michael.keith_at_oracle.com>
Cc: jsr338-experts_at_jpa-spec.java.net
Date: 05/14/2012 01:17 AM
Subject: [jsr338-experts] Re: question regarding jta-data-source
Hi Michael and Pinaki,
Yes, I understood how this is supposed to work, however this does not and
can not work for us this way out-of-the box.
I think I forgot to emphasize, that we are not an ORM and are not using
JDBC connections.
Of course we can (and would) register a Synchronization object with the
global transaction.
But where should the container get the XAResource from? Because we are not
using JDBC connections, which implies, we
are not using any DataSource. So there is simply no way for the app server
to drive the XA protocol.
Unless of course, we would provide a "fake" XADataSource in a "fake" JDBC
driver, and given the pseudo-code assumption
from my previous mail, we would then just call "getConnection()" on the
jta-data-source (which points to an app server pool
configured with our "fake" JDBC driver, configured to return enlisted
connections) and don't actually use the result
of the "getConnection()" invocation (which is a dummy implementation
anyways)
I'm pretty sure, that my pseudo-code assumption is correct, mostly because
I can not think of any other straight-forward
(or even weird) way how to implement that in the app server.
So this would be the way to go for us.
Regards,
Christian
On Fri, May 11, 2012 at 10:45 PM, michael keith <michael.keith_at_oracle.com>
wrote:
Hi Christian,
Yes, that's pretty much how it works.
-Mike
On 11/05/2012 9:45 AM, Christian Romberg wrote:
Hi Mike,
Unlike ORMs, we need to provide the XAResource instances to the app
server
(which in turn are associated with our internal connections to the
database server)
But I guess, if the user just sees a DataSource, then that will be
an app server proxy which eventually delegates to the XADataSource
of
our "JDBC" driver (provided I configure a DataSource that returns
enlisted connection in the app server using our JDBC driver)
So my pseudo-code assumption of the app servers DataSource proxy is
like this:
public class ContainerDataSourceProxy implements DataSource {
XADataSource xaDs = ...; //XADataSource of the installed JDBC
driver for this pool
public Connection getConnection() throws SQLException {
XAConnection xaCon = xaDs.getXAConnection();
enlist(xaCon.getXAResource());
return xaCon.getConnection();
}
...
}
So we could simply call getConnection() (and not using the returned
value at all) to trigger the app servers
enlisting our XAResource.
Regards,
Christian
On Fri, May 11, 2012 at 3:14 PM, michael keith <
michael.keith_at_oracle.com> wrote:
Hi Christian,
The data source referenced by the jta-data-source name is a
DataSource provided by the container in JNDI. It is the same one
that any application could look up and use, hence it is a
javax.sql.DataSource.
XADataSource is an internal type used by the driver and container
to coordinate XA, but users of the data source are not expected to
participate at that level. The JPA provider acts like a client of
the data source, using its connections to read and write, so it
does not need to be aware of the XA protocol being implemented
underneath.
Hope this makes things clearer.
Regards,
-Mike
On 10/05/2012 7:50 AM, Christian Romberg wrote:
Hello,
It is not explicitly mentioned in the spec, but I guess I
can safely assume, that the data source denoted by
jta-data-source is of type "javax.sql.XADataSource"?
After the JPA implementation has obtained an XAConnection
from this XADataSource, is it expected to
to do any calls (and if so, in any specific order) on this
XAConnection?
E.g. is it necessary, to call XAConnection.getConnection()
to trigger that the app server calls
XAConnection.getXAResource()
on the very same XAConnection? Or is it sufficient to just
call "XADataSource.getXAConnection()" to trigger this?
(Some background: we don't use JDBC connections (being not
an ORM) and probably we would need to provide our own
XADataSource implementation, so that the app server picks up
our own XAResource implementation)
Thank you!
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 | www.db4o.com
--
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 | www.db4o.com
--
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 | www.db4o.com -- 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.
(image/gif attachment: graycol.gif)