[concurrency-interest] A new Lock implementation: FileLock
ian.griffiths at yellow-b.com
Tue Aug 30 10:05:35 EDT 2005
I tend to agree with Josh.
I've used Jini pretty widely for distributed, highly secure modules such
as storing session parameters and system parameters that have to
survive a crash. It has many qualities such as robustness and
"distributability". One quality it does lack glaringly is speed (which
is understandable as it's busy doing other things).
I've been working a lot recently with the problem of sharing data
between processes on the same machine. I have to run a number of
identical processes on the servers for a very stupid reason: Windows
won't allow a session greater than 1.6Gb and the machine has 8Gb of
memory. I would be quite happy to run one 6Gb process. But Hotspot isn't
So I'm stuck with the problem of sharing some files between applications.
A simple to use file lock would probably do the trick just nicely.
I would agree with one of the previous posters that j.u.c. is not the
place to put it. Probably in an io or communications package.
From: Joshua Bloch <jbloch at gmail.com>
To: Brian Goetz <brian at quiotix.com>
Cc: concurrency-interest at altair.cs.oswego.edu, Dawid Kurzyniec
<dawidk at mathcs.emory.edu>, gregg.wonderly at pobox.com
Date: Mon, 29 Aug 2005 21:39:11 -0700
Subject: Re: [concurrency-interest] A new Lock implementation: FileLock
> 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
> 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
> 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
> > > 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
> > This is a pretty compelling argument. Take caching; there are lots
> > good off-the-shelf caching products out there, but everyone rolls
> > own, because "they don't need something that big, they just need a
> > with expiration." Over time, they end up reinventing a pretty
> > complicated wheel.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest