Josh Berkus wrote:
> Anyway, I would vote for a first implemenation for 2PC which addressed the
> commit-then-crash issue in some expedient-but-not-reliable way, and putting
> 2PC in /contrib with a "not for production use" warning. Some people will
> use it in production anyway, and hopefully one or more of them will put in
> the dozens of hours required to make it reliable.
>
Josh,
you cannot put something that requires an FE/BE protocol change, ON
COMMIT extra work plus ON RESTART extra work into contrib.
The interim solution to Tom's concern is "ask the operator". His entire
point is based on the fact that there is no way to let the systems
figure out what's right in the case they lost communication and don't
know why. And for a system that just misses IP packets, there is no way
to figure out if it's just that someone tripped over the cable or if the
other building got nuked.
To figure out what happened was never the goal for the ARPA project.
Their goal was to continue communication as long as there is a possible
path. If that's gone, you're on your own ... sorry!
I think 2PC is of no use for things like replication with takeover on
failure in mind. At least it'd cause a major hickup in the system, and
since failurs tend to oscillate, I don't want to be anywhere close when
that collaborative throwup starts. But I do think that there is value in
distributed transactions. Well ... I *know* that there is.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #