[concurrency-interest] A new Lock implementation: FileLock

Ian Griffiths 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
and won'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.


-----Original Message-----
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
> 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.
>         Josh
> 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.
> > 
> > 
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list