Обсуждение: Re: Postgres XA support
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 >
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
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
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
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
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
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
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
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