[concurrency-interest] A new Lock implementation: FileLock
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