Re: Working toward a JTA 1.0.1 Compliant XADataSource

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Tue, Mar 5, 2013 at 12:45 PM, Bryan Varner <bvarner(at)polarislabs(dot)com>wrote:

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

there is already a maven patch in the works which I haven't finished
applying yet and it works with the current layout.

>
> 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<https://github.com/polarislabs/pgjdbc/compare/POLARIS_XA>
>
> What is the preferred method for doing this?
> Perhaps a github pull request? ;-)
>

Yes a github pull request is preferred

>
> 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<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
>
>
>
Thanks for the work!