On Aug 12, 2011, at 20:40 , Tuure Laurinolli wrote:
>
>> Updates will however propagate from the master to other slaves eventually so
>> a write from one slave is not immediately visible on all other slaves.
>>>> It sounds like eventual consistency from master to other slaves. if so, I
>>>> am interested in finding out details about Neo4j HA member nodes voting
>>>> quorum & arbitrater setup (assuming using zookeeper)
>
> Looking at the code, it seems that the transaction is first prepare()'d on
> the slave, then the prepared log shipped to the master, applied and committed
> there, and the master txid shipped back and used to commit the transaction on
> slave. However, the locks seem to be held (both on slave and master) until
> the slave finishes committing or rolling back, so no visibility problems
> should occur.
Further, the Transaction that MasterClient/MasterServer/MasterImpl creates on
server-side is apparently only ever really used to hold locks. It is always
rolled back (finishTransaction() in MasterImpl). This leads me to wonder if the
following scenario is possible:
- Slave A replicates T to master, master commits it and gets
ready to return txnId, client X reads it from master, master
crashes
- Is it guaranteed that slave A commits the txn locally
before a new master is elected (since a new master elected
at this point won't have T, and thus client X would have
read an update that never completed successfully
Clearly slave A cannot commit the transaction, and its client gets some sort of
error. Also, since master crashed, a new master will be elected and the
transaction will never have existed in the new cluster. Yet client X managed to
read the result, which will be wrong. Also, in this case, when master is
restarted, can it rejoin the cluster, since its state has diverged from that of
the cluster?
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
