Working toward a JTA 1.0.1 Compliant XADataSource - Mailing list pgsql-jdbc

I'd like to start this thread by thanking everyone for their input on the questions I had regarding the existing XA
implementationthis week. You have all been very supportive and very encouraging. Special thanks to Heikki and the rest
ofthe community for providing the existing XA support and helping us understand it. 


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. 


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.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
productfor everyone to use. This looks like a pretty good place to start doing that. 

It is my intent to contribute to an effort to expand and improve the XA support for PostgreSQL. I believe this can be
done.I believe a good balance of configurable trade-offs to meet more (if not all) of the JTA 1.0.1 specification can
befound. I believe a more compliant XA implementation can be robust and preform respectably. 

I also like to think this can happen fairly fast.

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

I've waited to announce our work on this until I was convinced we had the ability to pull it off and that it was in a
stateworth asking for input on. 

Right now, the XADataSource implementation in our POLARIS_XA branch passes the existing XADataSource test suite -- even
theinterleaving tests that were commented out for the old implementation. 
The new implementation already has code to support:
  * resource sharing
  * interleaving
  * suspend / resume / join
  * Achieves functional parity (according to the junit tests) with the existing driver.

There are several of us still working on filling in the implementation. We know we have quite a ways to go before this
is'production ready'. 
That said our situation is such that we are working to get our immediate needs met while trying hard to do so in a
mannerthat will not degrade or break existing uses of the XADataSource. We're going to need help in making sure we
don'thave horrible regressions. 

We'd like to invite critiques, comments, or pull requests from the rest of the community. Especially those of you
who'vehelped us reach this point (weather you knew it or not)! What can we do better? What things have we done wrong?
Whatproblems do you foresee? 
Now that there's what I'd consider a functional prototype let's get the conversation started.

What's the next step to getting this pushed upstream? What barriers do you foresee, and what can I (or anyone else) do
inthe meantime? Is this the appropriate communication channel for such things? 

Regards,
-Bryan Varner

Senior Developer
POLARIS Laboratories

The statements, views, and opinions expressed in this email are my own personal remarks, and do no represent or imply
anyobligation on behalf of my employer, POLARIS Laboratories. 

P.S. I'm scheduled to be on vacation next week, but I have a sneaking suspicion I'll be keeping tabs on this mailing
list.The other developers from our team who subscribe to this group, (Kirk Winters : kwinters at polarislabs.com, and
AdamGray : agray at polarislabs.com) will also be keeping tabs.