atomix / copycat

A novel implementation of the Raft consensus algorithm

Home Page:http://atomix.io/copycat

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

question about pessimistic case

publicocean0 opened this issue · comments

Hi , i trying to understand how to use your library. The documentation is clear but there is a thing i dont understand.It explains when all goes well in the transaction.But in the opposite case? Supposing there is Storage Key/Value S is a LSM-like storage,Nodes F,A,B,C,D.
When you receive the Command "put" K,X ( to save a object X)
you see there is a conflict with another version of the object X.
For example the optimistic lock is not correct. In this case how to do? Commit class don t contains rollback.
Maybe throwing a exception (received also by sender)?
How to notify the cluster nodes it it is not possible to commit ? How to handle the error in the sender?

In my mind i thought a pseudo-code like it:

node F .put (K,x) {
TransactionalLog.putEntry("put",K,X);
copycat.send command->{
when command is accepted by quorum-> storage.save(X); TransactionalLog.removeEntry("put",X);
when command is reject by quorum ->TransactionalLog.removeEntry("put",X); throw rollbackException()
}
}

received from nodes A,B,C,D-> (A KO,b KO,C KO,D ok) --> the quorum is KO but i have to rollback
Probably TransactionalLog is already present in copycat so it is not necessary.
How to intercept Accepted/rejected?
example:
received from nodes A,B,C,D-> (A ok,b ok,C KO,D ok) --> the quorum is OK but i have to replair node C
in this case i have to not close the StateMachine commit in node C until i repaired the inconsistent status.

I thought a bit in the coffe:) i think all what i wrote above is wrong.

I m confused between replication and transaction.
Copy cat grant transaction log is consistent in the nodes. For handling the conflict between multiple concurrent write i have to use distributed locks.