[REBOL] Re: Multiuser database
From: SunandaDH:aol at: 22-Mar-2006 16:15
Gabriele:
> A good solution that hasn't been mentioned so far is to use a TCP
> listen port as the lock. Two processes are (or at least should
> not) never allowed to listen to the same port.
That's true on a single machine. But I think (if I read it right) the
original poster wanted to lock a resource on an application that is running (in
effect) asynchronously across a number of machines.
Gabriele:
> It probably should, but it's likely to be a pain to do in a
> multiplatform way (i.e. if we want the exact same behavior in all
> platforms)... not that I have studied the issue deeply, though.
I strongly suspect you are right -- the surface commonality would hide a
series of opsys-specific locking/semaphoring mechanisms; and then REBOL may be
reduced to implementing only the most common features. I can see why it isn't at
the top of Carl's to do list.
On the other hand, Ada had a rendezvous mechanism (so, in effect semaphores)
and async built into the language from day 1. So it must be possible if you
have enough Government money.
Gabriele:
> The best solution is always to have a single-threaded process
> providing serialized access to the given resource. When you can't
> do that, you are forced to deal with troubles.
Absolutely. Let me describe a slightly OT example I had to design a couple
of years back.
It's a humungous legacy application now sprawled across multiple mainframes
with hunks chopped off and running on various PC-class machines. And all of a
sudden we needed to lock a resource at the application level.
Providing a mainframe-wide lock was trivial -- ENQ and DEQ (enqueue and
dequeue) have been doing that since before Neal Armstrong bounced around on the
moon.
A PC-network-wide lock as almost as simple as the PC-side applications used a
common SQL database: so we just added a lock table in a simpler manner than
the lock files described in earlier posts in this thread. Then some things come
for free: like an uncommitted read lets you "peek" at the lock setting
without blocking yourself.
But combining those two make a single application-wide lock that was
foolproof and resilient (so if one side died the other side wasn't blocked) -- well,
that was fun.
Sunanda.
