Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> The simplest senario(though there could be varations) is
> [At participant(master)'s side]
> Because the commit operations is done, does nothing.
> [At coordinator(slave)' side]
> 1) After a while
> 2) re-establish the communication path between the
> partcipant(master)'s TM.
> 3) resend the "commit requeset" to the participant's TM.
> 1)2)3) would be repeated until the coordinator receives
> the "commit ok" message from the partcipant.
[ scratches head ] I think you are using the terms "master" and "slave"
oppositely than I would. But in any case, this is not an answer to the
concern I had. You're assuming that the "coordinator(slave)" side is
willing to resend a request indefinitely, and also that the
"participant(master)" side is willing to retain per-transaction commit
state indefinitely so that it can correctly answer belated questions
from the other side. What I was complaining about was that I don't
think either side can afford to remember per-transaction state
indefinitely. 2PC in the abstract is a useless academic abstraction ---
where the rubber meets the road is defining how you cope with failures
in the commit protocol.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
