Re: Re: [pgjdbc] XADataSource support for resource sharing & interleaving. (#47) - Mailing list pgsql-jdbc

> If we must have this anyway, I think we should try to implement it as a
> generic wrapper that could be used with any XADataSource implementation.

I think you mean DataSource implementation. So long as the underlying
RDBMS supports prepared transactions, there's no reason a wrapper
couldn't handle -all- of the XA bits.

For the purposes POLARIS Laboratories had, it was easier / faster for us
to get the behavior we needed starting from a stable build of the pg
driver and implementing this stuff in the driver code.

The immediate problem POLARIS faced was the driver implementing
XADataSource properly -- that is, as defined in the javadocs / JTA 1.0.1
spec. This patch addresses those shortcomings.

I'm not opposed to pulling it out into a wrapper, but what you're
describing in doing so is a new F/OSS project to accomplish that goal.
There will be some overlap with other existing projects. DBCP provides a
pooling data source wrapper for drivers which don't provide it.
Hibernate has a system for providing dialect-specific SQL, which we'll
need to handle prepare() commit() rollback() recover() of 2pc operations
on a per-dialect basis. This becomes a much larger project with a much
larger scope -- one I'm not sure I can make a case for my employer to
support.

> I also wonder if we could grab some low-hanging fruit without doing the
> whole pooling thing.

It's not really a 'pool'. It's a list of physical connections bound to a
logical connection context.

> For example, if you try to call (2nd phase)
> commit() on an connection that's currently busy with another
> transaction, instead of throwing an error we could open a new temporary
> connection, issue the COMMIT PREPARED, and disconnect.

And then you'll try to mitigate the performance issue (which is very
noticeable in that situation), and end up keeping track of a list of
connections.

> Sure, that would
> be slow, so you'd definitely still want to configure the TM to not do
> that, but at least it would work.

We evaluated what it would take to get pgjdbc to work with GlassFish's
TM as is. There are cases in our application where it does SUSPEND. What
you are proposing will not fix the missing support for SUSPEND / JOIN.

Honestly, I don't understand why all these drivers did such a half-baked
job of implementing the spec, or why you're so vocally defending a
half-implementation when it took two people bouncing ideas, code, and
testing a week to get it workable, and a few additional weeks to
stabilize it.

I think it's completely unreasonable to expect the reference
implementation of a container that follows specifications to provide a
workaround for non-compliant drivers which incorrectly implement a
well-documented interface. It's not the fault of the GlassFish project
that the standing XA implementation in pgjdbc (or any other driver) sucks.

Regards,
-Bryan Varner

---------------
The views expressed in this communication are the sole responsibility of
the author and do not reflect those of POLARIS Laboratories.