On Tue, 16 Aug 2005, Oliver Jowett wrote:
> Michael Allman wrote:
>
>> Key to the protocol is the ability to start and end the association of
>> transactions to threads of control. In particular, what's bothering me
>> is that there appears to be no way to end the transaction association of
>> the current postgres connection, either permanently or for suspension.
>> Please correct me if I'm wrong.
>>
>> Thus work performed using the underlying physical connection of a
>> PGXAResource unassociated with any transaction will still be performed
>> on the connection's transaction.
>
> You'll need another layer to support all of XA's behaviour -- this was
> the discussion about mapping XA connections to physical connections that
> happened on the list a while back, wasn't it?
>
> It's probably unnecessary for the first cut, though. What exactly is the
> behaviour that you can't support without that extra layer, and is it
> needed for common use of XA? Seems to me that you could get away with
> just disallowing work on a Connection that has an unprepared XA
> transaction pending.
You can do something like that to flag unsupported behavior, but I think
that without the ability to suspend and resume transaction branch
association, the JDBC XA support will not graduate from "experimental"
status. I couldn't confidently recommend it for production use, and I
wrote the damn thing.
I am pretty much decided that the JDBC XA support will require another
approach. If you really want to use my patchset, I will at least upload
the latest version which includes some fixes and more verbose
XAExceptions. But I'm not sold on it myself anymore.
I think JDBC XA is going to require a lot more work. The server-side 2PC
support coming in postgres 8.1 is a good thing, but it's not XA.
Michael
