Thread: Re: Postgres XA support

Re: Postgres XA support

From
Michael Allman
Date:
Heikki,

After reviewing my code, I am beginning to doubt that PostgreSQL, even
with the new two-phase commit support, will support the XA protocol.

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.

I'm going to halt my work on the postgres jdbc xa support until I see a
way out.

I think it might take Postgres implementing the C language xa routines
from the DTP XA spec to implement XA support at the JDBC level.  If
postgres supports XA on the backend, then we should be able to implement
JDBC XA with some simple pass-throughs to stored procedures.  I think this
is what Oracle does.

I am not at all a C hacker, but the problem is interesting, and if I get
some time I'll look into hacking up the server-side xa support.  I think
the difficulty will be directly related to how tightly transactions are
coupled to threads on the backend.

Michael

On Mon, 15 Aug 2005, Heikki Linnakangas wrote:

> Hi Michael,
>
> What's the status of you XA implementation? Are you still working on it?
>
> - Heikki
>

Re: Postgres XA support

From
Oliver Jowett
Date:
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.

-O

Re: Postgres XA support

From
Michael Allman
Date:
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

Re: Postgres XA support

From
Tom Lane
Date:
Michael Allman <msa@allman.ms> writes:
> 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.

Oh, I just *love* someone unilaterally relocating the goal posts
months after the design and implementation are frozen.  Especially
when the new location isn't even inside the same stadium.

Given that this is not happening in 8.1, and there isn't anyone
signed up to make it happen in any future release, what sort of
functionality can you get without it?  I tend to agree with Oliver
that it's not obvious why this is a core component without which
there can be no useful functionality.

            regards, tom lane

Re: Postgres XA support

From
Oliver Jowett
Date:
Tom Lane wrote:
> Michael Allman <msa@allman.ms> writes:
>
>>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.
>
>
> Oh, I just *love* someone unilaterally relocating the goal posts
> months after the design and implementation are frozen.  Especially
> when the new location isn't even inside the same stadium.

As far as I can see, all of JTA/XA is implementable with the 8.1 stuff
-- it just needs extra work on the JDBC side to get all the behaviour there.

-O

Re: Postgres XA support

From
Oliver Jowett
Date:
Michael Allman wrote:

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

Let us know if you do upload this somewhere, it'll make a good starting
point if nothing else.

-O

Re: Postgres XA support

From
Heikki Linnakangas
Date:
On Mon, 15 Aug 2005, Michael Allman wrote:

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

Please send it anyway, at least we can take a look at it.

- Heikki

Re: Postgres XA support

From
Michael Allman
Date:
On Tue, 16 Aug 2005, Heikki Linnakangas wrote:

> On Mon, 15 Aug 2005, Michael Allman wrote:
>
>> 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.
>
> Please send it anyway, at least we can take a look at it.

I've uploaded my latest, and probably last, patchset to

http://allman.ms/pgjdbcxa/pgjdbcxa-20050816.jar

You're free to adapt it as you see fit.

It's incomplete and broken.  I've flagged known problem areas with
comments and runtime exceptions.

If you do decide to continue work on this, please contribute back to the
mailing list.

Thanks.

Michael

Re: Postgres XA support

From
Heikki Linnakangas
Date:
On Tue, 16 Aug 2005, Michael Allman wrote:

> On Tue, 16 Aug 2005, Heikki Linnakangas wrote:
>
>> On Mon, 15 Aug 2005, Michael Allman wrote:
>>
>>> 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.
>>
>> Please send it anyway, at least we can take a look at it.
>
> I've uploaded my latest, and probably last, patchset to
>
> http://allman.ms/pgjdbcxa/pgjdbcxa-20050816.jar
>
> You're free to adapt it as you see fit.
>
> It's incomplete and broken.  I've flagged known problem areas with comments
> and runtime exceptions.

Thanks, I'll take a look at it.

> If you do decide to continue work on this, please contribute back to the
> mailing list.

Sure.

- Heikki