avoid auto-collision on mutable files #391

New Issue

warner · 2008-04-23T18:49:37Z

warner commented

2008-04-23 18:49:37 +00:00

It would be convenient if there were no way to make a single Tahoe node
perform a colliding write with itself. What that means is that two
dirnode-mutate operations on the same directory, given to a single tahoe node
at about the same time, should result in two successes, rather than at least
one uncoordinated write error.

To accomplish this, we need:

a weakref table (in the client) that maps URI to DirectoryNode or
MutableFileNode instance, so that two operations on the same node
will use the same instance.
some locking/queueing/sequencing code in the DirectoryNode to cause
the second operation to wait until the first has finished. There is
already code for this purpose in MutableFileNode.

The fact that MutableFileNode.modify is covered by the MFN lock may
mean that we don't actually need any additional locking code in
DirectoryNode. But we still need the singleton table.

It would be convenient if there were no way to make a single Tahoe node perform a colliding write with itself. What that means is that two dirnode-mutate operations on the same directory, given to a single tahoe node at about the same time, should result in two successes, rather than at least one uncoordinated write error. To accomplish this, we need: * a weakref table (in the client) that maps URI to `DirectoryNode` or `MutableFileNode` instance, so that two operations on the same node will use the same instance. * some locking/queueing/sequencing code in the `DirectoryNode` to cause the second operation to wait until the first has finished. There is already code for this purpose in `MutableFileNode`. The fact that `MutableFileNode.modify` is covered by the MFN lock may mean that we don't actually need any additional locking code in `DirectoryNode`. But we still need the singleton table.