Fix possible race condition in lockers with session expiration #34

Closed
eric opened this Issue May 23, 2012 · 0 comments

2 participants

@eric
zk-ruby member

Right now it's possible for a locker to unlock a lock it didn't actually create:

  • client1 grab lock lock
  • client2 try to grab lock and wait
  • client1 session expires (lock released)
  • client2 gets lock
  • client2 releases lock and deletes parent
  • client3 grabs lock and creates parent
  • client1 has reconnected and releases lock (it didn't create)

The solution we've come up with is to track the ctime of the parent and only delete the lock if the ctime of the parent matches what we thought it was.

The reason why this works is if the parent hasn't been deleted, the sequence numbers of the lock files will always be increasing.

@slyphon slyphon added a commit that referenced this issue May 24, 2012
@slyphon slyphon implement the fix for #34
when lock path is created, we now cache the stat of the parent at that time,
allowing us to compare ctimes when we want to clean up. an unlock call on a
lock not owned by the current session will return false now.
e3939ef
@slyphon slyphon added a commit that closed this issue May 24, 2012
@slyphon slyphon update RELEASES file
close #34
814e025
@slyphon slyphon closed this in 814e025 May 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment