>>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:
DW> That's essentially what I did in my alternative Mj1 shlock.pl. I used a
DW> .LOCK subdirectory wherever I needed to lock files and just left the
DW> lock files around since it was more work to remove and create them all
DW> the time, although it does create lock files when it needs them (it
DW> just doesn't ever remove them).
The non-removal is the problem, though. The issue is that Mj2 does a lot
of one-off things (namely sessions and spooled files) that have essentially
random names. For just about everything else it's OK to let the lockfiles
stick around, but for session info you have an essentially unbounded number
of little lockfile droppings sitting around.
Because of all of this trouble, because of the statistical impossibility of
having two sessions with the same session ID at the same time and because
of the non-critical nature of sessions I'm considering just not locking the
session files. That still leaves the spool files, which are allocated with
unique names but which contain important data. These accumulate at a
less-speedy rate (once per message that needs approval) but the number is
still unbounded.
I suppose I could do some more thinking and come up with ways to eliminate
the lockfiles in many cases, but that still doesn't solve the basic
problem.
DW> Since DBMSs were mentioned, one could do a similar trick and have a Mj
DW> lock daemon that serialized resource accesses through a network
DW> socket.
This really is getting out of hand, though. There have to be limits on the
complexity somewhere. I don't think I'm willing to go that far.
DW> Maybe just locking token lock files in an out-of-the-way place isn't so
DW> bad after all.
Well, that's what happens now anyway. It just seems too complicated when
you try to expire the locks without pain.
DW> You only need to remove the ones that have no matching data file (and
DW> haven't been created within the previous N time units?) and then only
DW> when you feel like it, i.e. once a day, once a week, etc.
It is easy to come up with situations where this causes corruption. In
practise they are really, really rare and when you're dealing with data
files that have statistically improbable names the chance of conflict is
reduced even further, but having races at all bothers me.
BTW, the locking in Mj2 is replaceable; the lock module only has to provide
the following methods: new, DESTROY, lock, unlock, and expire_locks. These
only have to provide two kinds of locks: shared and exclusive.
- J<
References:
|
|
