Implementation of strong consistency using locks#387
Implementation of strong consistency using locks#387peterzeller wants to merge 11 commits intomasterfrom
Conversation
|
From the documentation:
What message is then sent to the client? |
| @@ -0,0 +1,58 @@ | |||
| %% ------------------------------------------------------------------- | |||
| %% | |||
| %% Copyright <2013-2018> < | |||
There was a problem hiding this comment.
Shouldn't this become 2019?
There was a problem hiding this comment.
It's the same in other files. I can create a separate PR to update the date everywhere.
src/antidote_lock_server.erl
Outdated
| read_write_process = spawn_link(fun() -> read_write_process(Self) end) | ||
| }}. | ||
|
|
||
| %%check_lock_state_process(Pid) -> |
|
|
||
| - *Dynamic Membership*: Adding and removing DCs is currently not supported. | ||
| - *Fault tolerance*: In the following scenarios, the current implementation will not work correctly: | ||
| - CRDT state cannot be updated locally: Implementation will wait for the update indefinitely. |
There was a problem hiding this comment.
I don't understand this comment: Which CRDT state update is blocking here?
There was a problem hiding this comment.
When a lock is updated I am using an CRDT update operation. This update might fail, e.g. if the partition with the lock is currently not available. There is no error handling for this case yet.
src/antidote_lock_server_state.erl
Outdated
| {Actions, NewState}. | ||
|
|
||
|
|
||
| %%% computes lock request actions for the locally waiting locks |
|
Using |
3 participants
This PR adds support for strongly consistent (serializable) transactions by using Locks.
Current status:
There is still one failing test case:
The
cluster_failure_test_2sometimes fails. The test crashes a node holding the locks and then restarts it after some time. After the restart, another DC should be able to get the locks again, but the crashed DC sometimes is not able to read its CRDT state after restarting. I still have to debug this case - I am not yet sure if this is a problem with the lock implementation or a general problem in Antidote. Unfortunately, the bug occurs less frequently the more log messages I add for debugging.The rest of the implementation should be working.
Documentation is available in https://github.com/AntidoteDB/antidote/blob/strong-consistency-3/src/antidote_locks.md