On Fri, Sep 26, 2003 at 05:15:37PM -0400, Rod Taylor wrote:
> > The first problem is the restart/rejoin problem. When a 2PC member
> > goes away, it is supposed to come back with all its former locks and
> > everything in place, so that it can know what to do. This is also
> > extremely tricky, but I think the answer is sort of easy. A member
> > which re-joins without crashing (that is, it has open transactions,
>
> I think you may be confusing 2PC with replication.
No, I'm not. One needs to decide how to handle the situation where a
slave database in a 2PC transaction goes away and comes back, for
whatever reasons that may happen. Since the idea here is to come up
with ways of handling the failure of 2PC in some cases, we need
something which notices that members are not playing nice.
> PostgreSQLs 2PC implementation should follow enough of the XA rules to
> play nice in a mixed environment where something else is managing the
> transactions (application servers are becoming more common all the
> time).
I agree. But we still need to decide how to handle cases where
things go away, and if there are some transaction managers that don't
fit that model, then we should not accept such managers. Of course,
what such managers do is important data in deciding what sorts of
compromises are acceptable.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8 +1 416 646 3304
x110