Re: Working toward a JTA 1.0.1 Compliant XADataSource

On 16.02.2013 09:16, Bryan Viarner wrote:
> For our application and middleware stack we've not had any luck making minor adjustments to improve the issues we've
beenhaving. My early panic about serialized methods did help to eliminate one class of errors in our test environment
(oncewe were finally able to duplicate the issue), but culminated in exposing the lack of interleaving or shareable
XAResourcesfor 2pc operations with the GlassFish transaction manager as the ultimate culprit for our issues. It seems
thatwhen GlassFish gets busy (and your resource pool gets busy) it starts expecting some aspects of interleaving -- in
theform of commit(xid1, false) after start(xid2, NOFLAGS) has been issued to an XAResource. 

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.

> As has been discussed on this list earlier in the week an implementation that truly implements JTA 1.0.1, or at least
supportsinterleaving will bring a new set of trade-offs. Such an implementation would also make more complex JEE
deploymentsatop PostgreSQL possible (and more reliable, as in our case) for a wider set of containers and transaction
managers.

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.

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.

For example, in JBoss the option is called "track-connection-by-tx".
Since JBoss 5, the default is "true", so you don't need to remember to
set it manually anymore. I'm guessing that the JBoss developers decided
that it's better to set it by default, because in practice most
connector implementations require it to be set.

On Atomikos, the setting is called "com.atomikos.icatch.threaded_2pc",
and they also seem to have switched the default to false (ie. the right
option for PostgreSQL") in version 3.7.

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.

> 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
foreveryone 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.

> On behalf of the development team I've been working with on this the last few days, I'd like to invite any interested
partyto take a peek at what we're doing on github. 
> 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.

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? 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.

- Heikki