[concurrency-interest] A new Lock implementation: FileLock
gregg at cytetech.com
Mon Aug 29 19:54:47 EDT 2005
Dawid Kurzyniec wrote:
> Gregg Wonderly wrote:
>> 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.
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.
Look at the 8 fallacies of distributed computing and replace network with filesystem, or process and you'll find that
the parallels are very telling.
It is short sighted views of expansion and potential impact that are the foundation of the events that are reflected in
the 8 fallacies of distributed computing.
It might feel like you're carrying around a cannon. But when you might someday have to sink the whole ship, it's always
nice to have the correct tools already in hand. Investing in the right technology base has always rewarded me with many
more opportunities to exploit what I have done. In the case of Jini, I can distributed my applications on one or more
machines as needed. The operations between processes work no matter what environment I deploy in.
There will always be time/space tradeoffs to be considered, but I think this problem has already be solved and there
really is not a new solution needed.
There might instead need to be some exploration done in how to optimize marshalling/unmarshalling, or other parts of the
JERI/RMI stack. This might make the time/space tradeoffs work out to allow some applications to use less hardware.
But, the cost of hardware at a fixed price, compared to the unbounded cost of fixing or dealing with marginal/broken
software is a pretty compelling argument for using something that is already proven and well defined in operation,
complexity and scalability (you can measure the performance and calculate the hardware/network needs).
More information about the Concurrency-interest