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:[email protected]?subject=Unsubscribe
