users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: question regarding jta-data-source

From: Christian Romberg <cromberg_at_versant.com>
Date: Mon, 14 May 2012 15:17:45 +0200

Looks like that besides a Synchronization object, we can also register our
XADataSource directly via the javax.transaction.Transaction interface.

If the JTA implementation is allowed to lookup the transaction manager for
the purpose of registering a Synchronization instance, then
I expect it permission-wise not to be a problem, to also register an
XADataSource.

This would be an alternative to write a "fake" JDBC driver.

On Mon, May 14, 2012 at 2:54 PM, Christian Romberg <cromberg_at_versant.com>wrote:

> Mike,
>
> Adding the indirection of a resource adapter only adds an indirection, but
> the control flow stays the same.
>
> Also we had our huge share of experiences with JCA in the past, cough,
> cough, then better a fake JDBC directly,
> at least JDBC connection pools should be properly tested and scalable in
> every app server.
>
> Alternatively I have to research the JTA spec, whether there is a
> compliant way to register an XADataSource directly
> with the transaction manager, which could also work.
>
> Christian
>
>
> On Mon, May 14, 2012 at 2:42 PM, michael keith <michael.keith_at_oracle.com>wrote:
>
>> Christian,
>>
>> Non-JDBC data sources are typically deployed in the form of resource
>> adapters, using the connector SPI.
>> JPA was designed for JDBC data sources and drivers, not other kinds of
>> back end data. The spec can't help you, there.
>>
>> -Mike
>>
>>
>> On 14/05/2012 4:17 AM, Christian Romberg wrote:
>>
>> 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 <%2B49%2040%2060990-0>
>>>> (F) +49 40 60990-113 <%2B49%2040%2060990-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 <%2B49%2040%2060990-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.
>>
>>
>>
>>
>
>
> --
> 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.