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