MIT Incremental Propagation

[Ken Hornstein]

>Ubik is an elected-master protocol.  All updates go to the master
>which replicates.  If the master goes away, after a while the
>remaining nodes notice and revote a new master (this can take a while).
>
>I'm not sure that model works well with the KDC's single-threadedness.
>
>I expect a 3-phase commit model would be more robust.

I think you're conflating the master election protocol with the
transaction protocol.  You still need to decide on a master (aka
"coordinator") with 2PC or 3PC.  While Ubik does both the database
election and transaction protocol, this isn't really required.  And
from looking at the description of 3PC, I think Ubik as implemented
today would be considered 3PC, since transactions are aborted if a new
master needs to be elected.

Of course you wouldn't want to use Ubik as currently implemented today,
unless you really like having a dependency on AFS LWP & Rx.  I actually
wrote a completely new implementation of Ubik at one point ... the
recovery phase didn't quite work right, but I got busy with other things
before I could finish it.

As an aside ... I think the issue of the KDC being single/multithreaded
is a red herring.  I don't see a reason why the database update process
has to be part of the KDC process.  If you just restrict the multithreaded
parts to a seperate database update daemon, it shouldn't be a problem.

--Ken