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

I also agree, that such a big change should form a separate patch that
only performs the directory modifications, to confirm all permutations
of the existing build creates the same artifact after the re-arrangement.
Thanks
Stephen

I too, agree with this approach.

The current layout 'works' in netbeans, it just looks weird. There's no way (that we can find) to filter out the 'build' or non-source directories.

In the future, I'd really like to see the build system moved to something that allows us to easily push maven artifacts. I can't think of any reason maven central wouldn't accept this project for inclusion.

Our POLARIS_XA branch currently has everything moved back to '.'. However, I've retained the changes to build.xml which made it respect the 'srcdir' property. These are pretty minor changes, and they're tied up with our change to what java.in classes get filtered during the build. I don't think this should cause too much of an issue, and it will likely help make it clear what needs to be done if the build system is altered in the future.

At this point, we're actively trying to prep for an upstream patch.
https://github.com/polarislabs/pgjdbc/compare/POLARIS_XA

What is the preferred method for doing this?
   Perhaps a github pull request? ;-)

In our branch, the XA junit tests have been expanded quite a bit to exercise all the corner cases we've seen crop up. We've also been running the PGXADataSource against the jboss tm (narayana) QA test suite as an additional smoke-test. I will be getting in contact with the glassfish project (again) this week to determine what it takes to get the PGXADataSource listed as a supported configuration.

http://docs.oracle.com/cd/E18930_01/html/821-2416/beamw.html#gjksj

Interleaving is currently enabled by default, but can be disabled (set the xaAcquireTimeout parameter to 0). We do have test coverage for both situations. If a TM tries to do interleaving when it's disabled, you'll get an appropriate exception message telling you what to do about it.

Due to the nature of interleaving and isolation (and the way we've implemented it so far) there is not a 1-to-1 relationship between connections returned from the PGXADataSource and the number of physical DB connections to the back-end. The actual number of physical connections needed to service the XA invocations is totally application, workload, and TM dependent. If your TM never attempts interleaving, and your application doesn't do anything in local TX scopes, it's likely that you'll see 1-to-1 connection count ratios.

We've added a high-water mark count that logs when the logger is set to 'info' so you can get a fairly decent idea of what the driver is doing.

Because the physical connection count is so dependent upon application and TM, I don't feel comfortable giving a rule-of-thumb for configuring things here. What I can say is that, we're seeing that in cases of high-volume, we have about 12 physical connections per JVM more than the configured 'max pool size' in GlassFish.

That's all I can think of for now. If anyone wants to start testing builds, it should be reasonably safe to do so now.

Regards,
-Bryan Varner