brimdata
implement s3 emulation for PutIfNotExists
Suppose you think HEAD = 3 and you have a WRITE ready. Your WRITE is consistent for HEAD = 3. You check that LOG.4 and LOCK.4 do not exist. (If they do, you rebuild your WRITE based on the LOG.4 data and restart the process). If clear, you write LOCK.4 with your ID as content, wait for the ACK, then read LOCK.4 to see if no one else raced you and clobbered it. If you read it back and it’s you, there is still a chance that someone else clobbers it but you are allowed to move forward and write to LOG.4 (which includes your ID among the written data). Then you read back LOCK.4 and LOG.4 to make sure its both you. If not, you delete the file if any marked as yours and restart as above. If they are both marked as yours, you have safely written to HEAD and no other writer will have been able to enter the same state as you and will not subsequently clobber LOG.4 because they would have first had to clobber LOCK.4 before you read back LOG.4. At this point, you can safely delete LOCK.4 and HEAD is now at 4.
This seems incorrect. Please correct me if I'm wrong.
For my own sanity, I'm abbreviating LOCK.4 as L (lock) and LOG.4 as D (data).
Two concurrent nodes, A and B. Their IDs are a and b respectively.
- A: check that neither L nor D exist
- B: check that neither L nor D exist
- A: PUT L=a
- A: GET L, it's "a"
- A: PUT D=a
- A: GET L, it's "a"
- A: GET D, it's "a"
- B: PUT L=b
- B: GET L, it's "b"
- B: PUT D=b (A's data is destroyed here)
- A: DEL L
- A: claim success
- B: whatever, data is lost already
