🚀 go-pugleaf

Hmm. I think there are technical difficulties with Henry's
suggestions.

We lock the whole database so that only one user can every be
accumulating changes at one time.  When one user gets write access
that starts a new session and you lock against any others from getting
write access.  As changes are made they get written to disk (depends
on caches etc), but all objects touched in the new session are written
to new disk blocks.  Only when the user saves a session are the
indices and superblock rewritten, so up to that point any other user
starting up will get the old version.  (Also any crash will leave the
old version intact.)

Other users can not detect the update being made -- they have to quit
and start up again to pick it up.  Perhaps we could implement
something to check the superblock to check for this, but essentially
they would have to flush everything, in case it had changed.  The only
alternative would be a scan of all dynamically held data of all sorts,
which is a nightmare.

The problem with locking only during saving, which allows parallel
updating, is that if two users A and B take an object X, A edits it
and writes it back, and then B edits it tries to write it, the state B
is editing it from is not the last state of the database.  One
solution is to lock at the object level, not at the database level,
allowing several individuals to check out different objects.  However
that rapidly leads to deadlock situations, where two users are waiting
for each other to free something.  All very nasty.  Another is to do a
comparison when you save, to see if the object has changed under you.
But what to do if it has?  

Of course you are right that this is the same problem involved in
merging databases.  There we agreed that we need tools to highlight
clashes, but final fixing is up to the curator to manage.

As it is, the current sessions keep track of the user.  I don't see
the point in keeping the Unix pid.  Maybe the machine, though this
does not seem that relevant.  The date and time really should be there
-- currently they are not.  It is easy to add more information, since
the session is not just a "number", but also an ACEDB object.  We can
extend its model like any other (almost).  The "(almost)" is because
the sessions get treated slightly differently, being not under session
control themselves, and can only contain tags and data (Int, Float,
Text), not pointers to other objects.