> This isn't a good reason not to fix XADataSource, but it might be
> informative. If nothing else you can probably learn more about the
> JTA/XA requirements and tricks for interleaving, etc, from AS7's code.
We were in contact with some of the folks from the JBoss community
throughout our development. They were very helpful.
> I was not using 2PC and co-ordinating with other transaction managers,
> so it's entirely possible this only works for the
> one-datasource-per-XA-transaction case.
It sounds like you may have hit a use-case where you were
'automagically' getting the advantages of a Last Agent Optimization
approach. For our applications, we have multiple XA participants and the
LAO is not a feasible solution for us at this time.
There are properties in the JBoss TMs for disabling the use of
interleaving. Most TMs have properties like this. The GlassFish TM does
not. We are re-evaluating our container options. That will be a
long-term project and may solve our XA issues by allowing us to fiddle
with the TM behavior, but would not result in the PG jdbc driver
becoming more compliant with published specs. I don't hold the
unrealistic expectation that everyone will use TMs and containers that
work around bugs for specific drivers.
> Great, we'll almost certainly need that since someone's certain to be
> relying on it - intentionally or not - and unwilling/unable to change
> their code or the library they're using.
I would not have submitted a patch if the behavior to open additional
physical connections and disable interleaving support were not included.
It may even be more appropriate for this support to be disabled by
default. I'm somewhat surprised no one has demanded that rather than
debating the merits of weather or not suspend / join and resource
sharing should be supported at all.
Regards,
-Bryan