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

On 15.03.2013 20:48, Bryan Varner wrote:
>> 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.

Yeah, but there is no standardized way to work with the underlying
RDBM's prepared transactions, other than XADataSource. PostgreSQL uses
PREPARE TRANSACTION, other RDBMs have something else. I was thinking of
a wrapper that calls the native XADataSource implementation, which
doesn't need to support suspend/resume and interleaving, and presents a
fully-compliant XADataSource implementation to the outside, using the
technique you used.

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

Yeah, possibly. Or it could still be included in the org.postgresql
driver. I guess it depends on the details, on what exactly the wrapper
will look like.

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

I didn't understand that part. What does Hibernate have to do with this?

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

Did you evaluate what it would take to add the option to Glassfish?

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

The JTA specification is crap. It imposes requirements on the drivers
that have nothing to do with the real goal of the spec: supporting
two-phase commit. It's silly that drivers have to be complicated to
support those things.

If you look at the javadocs for XADataSource, it says for getXAConnection():

> Attempts to establish a *physical* database connection that can be used in a distributed transaction.

(emphasis mine). It's pretty clear what the intention of the authors is.
"physical" is a vague term, but you'd expect that typically to be a
single TCP connection, wouldn't you? It's not expected that the driver
needs a multiplexing layer, mapping a single XAConnection to multiple
physical connections.

Now, maybe it works fine with the multiplexing layer, but even if that's
the way to meet the letter of the JTA spec, I don't think it's in the
spirit of the spec that you'd have to do that.

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

Doesn't hurt to ask... They do have
xa-driver-does-not-support-non-tx-operations and
oracle-xa-recovery-workaround options, which are similar workarounds.

Regarding the patch itself:

Does it work correctly if you prepare a PreparedStatement in one
transaction, suspend, and try to use the prepared statement in another
transaction? I'm not sure what "correctly" is here, I don't think the
JTA spec says anything explicit about that scenario (it's crap, after
all ;-)), but I'd expect that to work.

It's a bit worrying that you can exceed your connection pool size with
this. In the worst case, a single logical connection can use an
arbitrary number of physical connections. That makes it more difficult
to set max_connections, so that you don't run out of slots. To an admin,
it's pretty surprising to see 50 connections from a host, when you've
configured the max connection pool size to 40.

- Heikki