Hi Henrik,

> Hi, I'm playing around with the syncing and getting behaviour that is not
> what I expected.
> ...
>    (dbSync (get *DB '+UserAttr))
> ...
>    (dbSync (get *DB '+User))

I think that 'dbSync' is not really what you want to use here. Perhaps I
explained this partially wrong last time in IRC, when we talked about
locking separate parts of the DB.

'dbSync' does too much here. The source is

   (de dbSync (Obj)
      (let *Run NIL
         (while (lock (or Obj *DB))
            (wait 40) )
         (sync) ) )

So in addition to the locking, it also does a 'sync'. And 'sync' waits
until a 'commit' or a 'rollback' is executed. This is necessary to keep
the caches of competing processes synchronized.

If you want (as I understand our discussion in IRC) just lock separate
parts of the DB, you use 'lock' directly.

BTW, you can do such testing much easier. Just connect from two terminals
to a running application with 'psh':

  Terminal 1:
      $ bin/psh 8080
      : (lock (get *DB '+UserAttr))
      -> NIL

  Terminal 2:
      $ bin/psh 8080
      : (lock (get *DB '+User))
      -> NIL

The 'NIL' indicates success in both cases ('lock' returns the PID of the
process holding the lock). You see this if you go on in Terminal 2 with

      : (lock (get *DB '+UserAttr))
      -> 30461

Such plain locks are used by the GUI (in "lib/form.l"), to allow just
one single user to edit a given object.

In any case, it is quite dangerous (or at least tricky) to run a
database without the 'sync' mechanisms. You must be absolutely sure that
no objects are modified which at the same time might be cached by other
processes. And _if_ this is the case, then you probably also don't need
to 'lock' anything (and just rely on the low-level locks in 'commit').

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to