Multi ops might help here although there might be some difficult because all
we have is an existence check and not a non-existence check.
One way to hack that is to have each normal file operation be a multi that
looks like this:
create lock, modify file, delete lock
The lock will never be visible since it is created and deleted in a single
atomic operation. This does guarantee that the modification will never
succeed if the lock file already exists.
The cleanup can proceed like this:
create lock
get children
delete old files with large multi-op
delete lock
This should be pretty darned fast since only for round-trips are required.
On Tue, Sep 20, 2011 at 12:37 PM, Jordan Zimmerman
<[email protected]>wrote:
> How can you safely clean up the path for each member ID lock? There
> doesn't seem to be an atomic way to do it. If one process is cleaning up
> for example "/locks/members/12345", it can't be sure than another process
> might need to get a lock on that member ID. I.e. There's never a safe
> point to delete "/locals/members/12345".
>
