[ Jason L Tibbitts III writes: ]
>
> Konfig file locking in Majordomo1 works as far as preventing reads while
> the actual write is occurring, but since Majordomo1 basically ships the
> entire file out to be edited and back on to disk there can be problems with
> variables that are automatically manipulated by the system.
Also if more than one person edits the c*nfig file at nearly the same
time, although that scenario is far less likely.
[ Mj2 solution deleted for brevity ]
> To further prevent accidental changes, variables like sequence_number are
> tagged 'auto' and are always presented to the user preceded by a warning
> and a comment character. This keeps these variables from being overwritten
> when the owner does a configshow ALL (or configedit ALL) and returns the
> results without editing out the automatic variables. The variable can of
> course be set, but some additional effort is required.
On the part of the user (removing the comment character?) or Mj2? Have
you considered embedding a signature/timestamp/sequence number in the
disk version which is included with queries that must be returned with
any edits to verify that no changes have occurred since the value was
retrieved? I haven't thought about what it should do if the tokens don't
agree. Maybe that should be a modifier to the change command, like a
"force" flag to make the change regardless but let the sender know that
the value changed (and the value that was overwritten). Without the
modifier, the change (all changes?) would be rejected and the new values
returned for another attempt.
Since Mj2 has the potential for longer run times because it delivers
messages instead of just handing them off, have you taken care that the
c*nfig files aren't being locked for extended periods? Or am I wrong
about the division of tasks such that c*nfig locking and long duration
tasks are never concurrent? (I know, you're thinking "Why don't you just
look in the source, Dave", but I really don't have time to take on
another job ;-) and I hope my distance gives me a more objective
viewpoint from which to see potential problems and solutions. Not that
it's done that so far...)
--
Dave Wolfe
Follow-Ups:
References:
|
|
