Oliver Jowett <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Well, the question is how long must the individual databases retain state with which to answer "recover" requests.
As I understand it, you don't need to keep state for committed txns,
I think that's clearly wrong:
TM --> DB: COMMIT PREPARED foo
DB does it and forgets gid foo
TM crashes and restarts
TM --> DB: what's the state of foo?
DB --> TM: go away, never heard of it
I suppose you could code the TM to treat this as meaning "it was committed"
I believe that is exactly what the TM does. Can you take a look at http://pybsddb.sourceforge.net/ref/xa/build.html (it's fairly brief) and point out any holes in the logic there?
but I think the folly of that is obvious.
It's fragile in the face of badly implemented TMs or resources, but other than that it seems OK to me. What was the problem you were thinking of in particular?
Yeah, there's another set of issues there. Personally I always thought that 2PC was a fundamentally broken concept, because it's got so many squirrelly cases where the guarantees you thought you were buying with all this overhead vanish into thin air.
You can get around some of the issues via 3PC but that has even *more* overhead. And noone actually implements it as far as I know :)
2PC is OK if you are only expecting it to handle certain failure modes, e.g. no byzantine failures, no loss of stable storage, no extended communication failures.
In general, the two-army problem just sucks..
-O
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
