[concurrency-interest] A new Lock implementation: FileLock

Joshua Bloch jbloch at gmail.com
Tue Aug 30 00:39:11 EDT 2005

I don't find this at all convincing.  When I was implementing
java.util.prefs, an interprocess locking mechanism was precisely what
I needed.  I did not need any of the other trappings of a full-blown
transaction system, and yes, I know what they are: I designed and
built distributed transaction systems for over a decade.

As for distributed vs. interprocess, the file-locking semantics of NFS
are supposed to be well-defined at to work properly.  I'm not sure if
this is really the case.  I would assume there are some good and some
bad implementations out there.

Jini is a large, complex AP consisting of 60+ packages! 
java.util.concurrency.locks.Lock has 6 methods.  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.


On 8/29/05, Brian Goetz <brian at quiotix.com> wrote:
> > My point is that a solution already exists.  If you think that you need
> > a same machine, interprocess solution today, chances are that tomorrow
> > you'll need a distributed version.  It may not happen that way, but the
> > failure scenarios and all of the situations that develop on an
> > interprocess solution are exactly what happen in a distributed system.
> This is a pretty compelling argument.  Take caching; there are lots of
> good off-the-shelf caching products out there, but everyone rolls their
> own, because "they don't need something that big, they just need a Map
> with expiration."  Over time, they end up reinventing a pretty
> complicated wheel.

More information about the Concurrency-interest mailing list