Hi Scott,
This is indeed a good idea, so I think we will introduce a versant specific
property which (if specified) takes precedence over
our probing algorithms to find the TM.
Christian
On Thu, May 17, 2012 at 8:46 PM, Scott Marlow <smarlow_at_redhat.com> wrote:
> 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
>> TransactionSynchronizationRegi**stry, 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<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 <michael.keith_at_oracle.com>>>
>> Cc: jsr338-experts_at_jpa-spec.java.**net<jsr338-experts_at_jpa-spec.java.net>
>> <mailto:jsr338-experts_at_jpa-**spec.java.net<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<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<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<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=**
>> AFrqEzdo3Q40RwKQPBtnPIuBYQd1di**FxJQ<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<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=**AFrqEzdo3Q40RwKQPBtnPIuBYQd1di**FxJQ<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<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=**AFrqEzdo3Q40RwKQPBtnPIuBYQd1di**FxJQ<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<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=**AFrqEzdo3Q40RwKQPBtnPIuBYQd1di**FxJQ<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.