[concurrency-interest] A new Lock implementation: FileLock

Dawid Kurzyniec dawidk at mathcs.emory.edu
Mon Aug 29 17:08:11 EDT 2005

Gregg Wonderly wrote:

>> (4) People would use FileLocks across physical machines, using NFS
>> files.  This might work reliably.  Or it might not.  If it didn't,
>> they'd get angry at me.
>> Anyway, if you are so inclined, take a look at it and tell me what you
>> think.  When I first came up with the idea, I thought it might make a
>> nice addition to j.u.c, but now I'm not so sure.
> For remote, distributed capabilities, the Jini platform's transaction 
> manager
> really provides a crash resilent implementation.  The configurabilty and
> flexibility at deployment provides a great way to make things as 
> effecient or as
> secure as you need.
> I know Jini is not in the J2SE, but at some point, I hope people who need
> distributed solutions will come to realize what power and capabilities
> are in Jini.
> There's really not an interesting reason to recreate all of that work.

I hope that your point is that distributed file locking is not a 
reliable substitute for a transaction manager, be it Jini or otherwise, 
when one is needed. If so, I fully agree. On the other hand, distributed 
transaction manager is shooting flies from a cannon if all you need is 
basic non-distributed inter-process synchronization. (Carrying that 
cannon around, no matter how well-featured it is, will cost you in terms 
of deployment size and complexity, and run-time overheads of two-phase 
commit etc.) So, all in all I am happy to see this file lock 
implementation, even if it is prone to abuse (what isn't?). However, I 
am not very sure if it belongs to j.u.c., as the latter is very "core" 
and compact, and single-JVM-oriented. My feeling is that a file lock 
would stick out. But, for instance, I think it would make a good 
candidate for an online article.


More information about the Concurrency-interest mailing list