Re: Two-phase commit - Mailing list pgsql-hackers

From devik@cdi.cz
Subject Re: Two-phase commit
Date
Msg-id 39F69607.96A60C28@cdi.cz
Whole thread Raw
In response to Re: Two-phase commit  (richard excite <richard_excite@excite.com>)
List pgsql-hackers
hello,
I'm not sure what will your lib solve ? For reliable
distributed TX, each SQL server have to support two
phase commit. It means to have at least PREPARE command
which is identical to COMMIT only doesn't really commit
(last commit bit is not written but TX is at commit edge
and can't complain to COMMIT cmd).
Also is should provide interface/way for querying state
of particular TX (identified by XID) and if it is in
PREPARED state then way to commit/rollback it: it is
for cases when connection between PG and XA manager
terminates between PREPARE and COMMIT/ABORT. PG then
also should continue to hold all "locks" (or
HEAP_MARKED_FOR_UPDATE in PG) until PREPARED TX is
resolved.
Probably it should not be hard .. ?
devik

richard excite wrote:
> 
> i'm developing one. a library for batch transactions, so you
> can continue processing in the middle of the file(or table) in
> case an abort happens. it can support multi-databases.
> i think i can share it to freshmeat.
> 
> On Tue, 24 Oct 2000 13:52:38 +0200, devik@cdi.cz wrote:
> 
> >  Hello,
> >  anyone thought about implementing two-phase commit to
> >  be able to support distributed transactions ?
> >  I have no clue how complex it would be, someone knows ?
> >
> >  devik
> >
> >
> 
> _______________________________________________________
> Say Bye to Slow Internet!
> http://www.home.com/xinbox/signup.html




pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: AW: BLERe: AW: AW: relation ### modified whilein use
Next
From: devik@cdi.cz
Date:
Subject: Unneccessary cmax in heap tuple ?