Re: Working toward a JTA 1.0.1 Compliant XADataSource

For what it's worth Bryan I thing what you're doing is a good thing,
this makes the implementation more robust and I'll be testing what you
have as soon as I find the time.

Thanks,
Florent

On Fri, Feb 15, 2013 at 11:16 PM, Bryan Varner <bvarner(at)polarislabs(dot)com> wrote:
> I'd like to start this thread by thanking everyone for their input on the questions I had regarding the existing XA implementation this week. You have all been very supportive and very encouraging. Special thanks to Heikki and the rest of the 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 been having. My early panic about serialized methods did help to eliminate one class of errors in our test environment (once we were finally able to duplicate the issue), but culminated in exposing the lack of interleaving or shareable XAResources for 2pc operations with the GlassFish transaction manager as the ultimate culprit for our issues. It seems that when GlassFish gets busy (and your resource pool gets busy) it starts expecting some aspects of interleaving -- in the form 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 supports interleaving will bring a new set of trade-offs. Such an implementation would also make more complex JEE deployments atop 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 product for 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 be found. 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 party to 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 state worth asking for input on.
>
> Right now, the XADataSource implementation in our POLARIS_XA branch passes the existing XADataSource test suite -- even the interleaving 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 manner that will not degrade or break existing uses of the XADataSource. We're going to need help in making sure we don't have horrible regressions.
>
> We'd like to invite critiques, comments, or pull requests from the rest of the community. Especially those of you who've helped us reach this point (weather you knew it or not)! What can we do better? What things have we done wrong? What problems 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 in the 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 any obligation 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 Adam Gray : agray at polarislabs.com) will also be keeping tabs.

--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87