Re: Working toward a JTA 1.0.1 Compliant XADataSource

> Sorry to hear that. I'd be interested to have an isolated, stand-alone
> test application that reproduces the problem, so that I could also play
> with it.

Now that we've been able to reproduce it in our test environments, it's
far more likely we can do that. I'd be happy to send you some debug logs
from the pgjdbc driver, where it documented what was going on.

> Frankly, I don't think this is worth the trouble, or worth complicating
> the driver for. It would be nice to be fully compliant, just so we could
> say that we are, but in practice, meh.

If the existing implementation actually worked for my case, I'd agree
with you. It's not working for me, so at this point, I disagree.

> The PostgreSQL driver is not alone with the limitations. I believe
> Oracle has similar limitations, as does MySQL, and DB2. Which is why all
> application servers I've bumped into this far have options to work
> around them. I'm very surprised if Glassfish doesn't. In practice, a
> transaction manager that insists on working support for transaction
> interleaving and suspend/resume, is pretty useless.

While we are not seeing join / suspend / resume, we are seeing the
expectation that you can commit a previously prepared TX while already
working on a new TX. I've read the JTA specification through several
times at this point, and I'm not sure if that should be considered
interleaving, or properly implementing the resource sharing aspect of
XAResource.

Here's the configuration options for the GlassFish version we're using.
http://docs.oracle.com/cd/E18930_01/html/821-2416/beanp.html#scrolltoc

The closest thing to interleaving I see is
ALLOW_MULTIPLE_ENLISTS_DELISTS, which is disabled (false) by default.

> IMHO it was a serious mistake from the JTA spec authors to require those
> extra features. They are not required for robust two-phase commit, and
> are difficult to implement in many JDBC drivers, including PostgreSQL's.

I too, hope this gets fixed in the 2.0 spec.

>> We love PostgreSQL. It's done very well for us in the past and we'd
>> like to give back by making it a better product for everyone to use.
>> This looks like a pretty good place to start doing that.
>
> I think the best action here would be to expand the FAQ with specific
> information on how to set up the data source on various app servers
> (http://jdbc.postgresql.org/documentation/faq.html). And if Glassfish
> doesn't yet provide a suitable work-around option, petition them to
> implement one.

I have been in contact with a few of the GlassFish developers. I will
try to see if there is something they could do in a future version.

GlassFish is a bigger, slower moving project at this point, and I don't
have the time to wait for them to change their JTA implementation.

>> https://github.com/polarislabs/pgjdbc/tree/POLARIS_XA
>
> There seems to be some unrelated refactoring in this branch, moving
> files around, so it's a bit hard to see what the real changes are.

To get better support for code completion in a few IDE's we moved things
into a 'src' directory, and updated the build.xml to handle it.

We added a protected method to the PGPoolingConnection so that
subclasses can obtain the underlying Connection without having to cache
it as a private member variable.

The XADataSource now implements most of the XA control invocation, and
extends AbstractXADataSource, which is the file filtered to extend the
proper spec version implementation by the ant build.

> One random thought just occurred to me: while I don't think this is
> worth the complexity in the PostgreSQL driver, would it be possible to
> implement this as a generic wrapper that could be used with any
> XADataSource implementation?

That's essentially what we're doing with this implementation... except
that we're tied to the pgjdbc build system to make sure we build for the
right version of the jdbc spec, and the PostgreSQL dialect.

It certainly would be 'possible' to wrap a normal DataSource into an XA
compliant pool and provide different implementations for different spec
versions and dialects.

> The concept of implementing the transaction
> interleaving and suspend/resume by adding yet another layer of pooling
> seems pretty universal. It could then be used with any application
> server which doesn't already provide a work-around option, and with any
> JDBC implementation that has these limitations.

Having it work for 'any' database is a lofty goal, would take a lot more
time, and won't help address the problem I have any faster. From a
practical engineering standpoint, what you're proposing is a very large
undertaking, and one that won't help me resolve my situation any faster
than sticking to one database, one driver, and two jdbc version specs.

Regards,
-Bryan Varner