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