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