copycat icon indicating copy to clipboard operation
copycat copied to clipboard

question about pessimistic case

Open publicocean0 opened this issue 9 years ago • 1 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.

publicocean0 avatar Apr 15 '17 10:04 publicocean0

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.

publicocean0 avatar Apr 15 '17 14:04 publicocean0