[concurrency-interest] A new Lock implementation: FileLock

Gregg Wonderly gregg at cytetech.com
Tue Aug 30 14:37:19 EDT 2005

Joshua Bloch wrote:
>>There are many parts of Jini which you don't need for such things.
>>>java.util.concurrency.locks.Lock has 6 methods.
>>I understand this thought, but it in fact uses the whole JVM implementation which is many more lines of code than Jini.
> That is utterly irrelevant.  Who cares how many lines of code there
> are in the JVM *implementation*?  We are talking about the conceptual
> weight of an interface.  The target audience for this class already
> knows the java.util.concurrent.locks.Lock *interface*, so the marginal
> conceptual weight of this implementation is pretty close to zero.  The
> audience does not know Jini, and the marginal conceptual weight to
> learn it is large.

I guess I'm missing the irrelevancy when you suggesting something based on NFS that would require learning about NFS 
semantics, installing an NFS based filesystem implementation etc.  There are barriers everywhere Josh.  I'm not trying 
to undermine your idea, I'm trying to suggest that there are tools that might make it easier.

>>One example might be that you ran out of space on the file system.  Half of the data made it to disk, the other half is
>>still pending, or lost.  But, the file system is actively aquiring new space, and you'd really like to let the failed
>>writer finish its job, before letting other writers put their data in there.  However, at some point, you want progress
>>to be made.  If the releasing process actually exited when the write failed because it has a bug, you could use a
>>distributed lease to finally expire the access lock unconditionally and move on with some type of cleanup.
> Typically you create a new file, and atomically replace the old one by
> changing the name of the new one.  If you run out of space creating
> the new one, the old one never changes.  This is what I did in
> java.util.prefs. It is crude but effective.

This is a pretty typical mechanism for small files.  But large mailbox files as was Dawid's example, would typically not 
be replicated as a safety measure.  There are variations on every theme.  And points and counter points can be brought 
up.  I'm trying to share my experiences.   I'm sorry I'm such a lousy communicator.

> This is the last I will say on this subtopic; you may have the last
> word if it pleases you.

I am not trying to gain pleasure here.  I am sorry you feel attacked or otherwise abused by my comments.  Please accept 
my apologies.

Gregg Wonderly

More information about the Concurrency-interest mailing list