On 05/15/2012 03:26 AM, Christian Romberg wrote:
> Hi Pinaki,
>
> As I pointed out, it would only be a "fake" JDBC driver, I know, that
> the TM does not care, what type of resource is behind the XAResource,
> it's just that we need to enlist our XAResource with the current
> transactions.
> Either the app server picks it up itself (pull-approach, via a fake JDBC
> driver, or -in theory- a JCA adapter) or we enlist it directly
> (push-approach)
>
> > 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.
>
> Two simple reasons:
> -app servers do support JDBC connection pools and JCA is not a viable
> approach
> -there is no standard way to get access to the TransactionManager
> (however there is a standard way to get the
> TransactionSynchronizationRegistry, which is sufficient
> for other JPA implementations)
>
> However we will probably still use the alternative, to enlist our
> XAResource directly with the TransactionManager.
>
> So we will do some probing in the code, to find out which app server we
> are in and/or try out a list of well-known JNDI-names
> to look-up the TransactionManager.
It might be worth your while to introduce a Versant specific persistence
unit property for the TransactionManager to be passed in to you. That
might be useful in non-EE environments and some EE environments that
might be able to pass that in. Some other persistence providers contain
similar TransactionManager lookup code but that is a fragile solution
that can break over time (e.g.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=365704).
Persistence providers also aren't supposed to use the TransactionManager
in EE (since EE5). Otherwise, I think we could have a standard PU
property for passing the TransactionManager in.
>
> Regards,
>
> Christian
>
> On Mon, May 14, 2012 at 7:11 PM, Pinaki Poddar <ppoddar_at_us.ibm.com
> <mailto:ppoddar_at_us.ibm.com>> wrote:
>
> 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
>
>
>
>
>
>
> Inactive hide details for Christian Romberg ---05/14/2012 01:17:26
> AM---Hi Michael and Pinaki, Yes, I understood how this is su
> Christian Romberg ---05/14/2012 01:17:26 AM---Hi Michael and Pinaki,
> Yes, I understood how this is supposed to work, however this does
> not and
>
> From: Christian Romberg <cromberg_at_versant.com
> <mailto:cromberg_at_versant.com>>
>
> To: michael keith <michael.keith_at_oracle.com
> <mailto:michael.keith_at_oracle.com>>
> Cc: jsr338-experts_at_jpa-spec.java.net
> <mailto: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 <mailto: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 <mailto: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 <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 <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 <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.
>
>
>