How does the GUI framework work?

What if user A pulls upp object X in an update form and then goes to the
toilet and in the meantime user B pulls the same object and changes it,
will user A see any changes when he comes back?


On Sat, Jan 5, 2013 at 10:48 PM, Alexander Burger <a...@software-lab.de>wrote:

> 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