[concurrency-interest] A new Lock implementation: FileLock

Gregg Wonderly gregg at cytetech.com
Tue Aug 30 11:28:15 EDT 2005



Joshua Bloch wrote:
> Jini is a large, complex AP consisting of 60+ packages! 

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. 
  You're willing to accept the requirement to use Java for your application.  So I'm not sure how valid of an argument 
size is.  Jini is a toolkit, just like the Java platform is.  It's targeted at providing solutions to some specific 
types of problems.  Those problems are not trivial in nature, but can appear minimal at first glance.

 > If I can save someone
> from having to learn the former by introducing a special-purpose
> implementation of the latter, I've done a good deed.  I don't see it
> as reimplementing the wheel.

You will recreate all the logic and trappings associated with distributed failures.  When an application releases the 
lock, does that mean that the now unlocked data is valid, or invalid?  How will you know?  A distributed transaction 
system would let you arrive at a safe point.

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.

Transactions and leasing allow things to progress in a way that all participating parties can agree with.  If you just 
implement the file lock, then you'll need some kind of IPC eventually to let the processes discuss how to handle 
different issues, I'd bet.  Its the development of the initial need verses the longterm needs of the application that 
can make the problem seem a lot smaller than it actually is.

The speed of distributed transactions can be many orders of magnitude slower than a single machine kernel based file 
lock, or an NFS file lock.  There are many exchanges between multiple processes.  It's an area where a lot of research 
and experimentation could be performed.  It might be that an NFS file lock based transaction implementation in Jini 
would be a great optimization.  I don't know.  However, I don't use NFS on any filesystems that my applications run on 
though, so that solution is not attractive from that point of view.

I have no doubt that many people on this list know precisely all of the issues that need to be dealt with.  I just 
detect a one small step at a time thought process that will, sure enough, allow you to get done what you want done. 
But, eventually, you'll recreate all the abilities that already exist in Jini, or are enabled my the tools in Jini, and 
that seems like a non-benefit to the Java platform.


Gregg Wonderly


More information about the Concurrency-interest mailing list