Re: ACID tests
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.dewrote:
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
Re: ACID tests
On Sat, Jan 05, 2013 at 11:25:30PM +0700, Henrik Sarvell wrote: 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? Yes. Try it ;-) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
picolisp org-mode blog
Hello all - Over the holiday I made some progress on the org-mode parser and rolled it into a blog engine. It's still very much a work in progress yet wanted to share it with the group for some early feedback. The cosmetics of the blog are last on my list. https://bitbucket.org/joebo/picoblogorg It still has a fair amount of debug code and cleanup left so it's not really ready yet for primetime. I figure it may be a useful example for someone wanting to build a picolisp web app using an alternative to the gui framework. A real app would likely also use the picolisp DB which I haven't needed to do in this app. I switched over my site to use it and am going to continue to post some updates as I go: http://csilo.com Cheers, Joe
Re: picoLisp on FreeBSD 9.1 x64
Hi Mansur, I tried different options, also without stripping, but with no success. Perhaps someone can help to write small assembly program with shared library for test dlopen/dlsym calls? What did you use for the 'LD-SHARED' linker options? The Makefile of 'pil32' uses -shared -export-dynamic for FreeBSD (in addition to -m32 which obviously doesn't make sense here). Perhaps this works for 64-bits too? An assembly program is probably not so helpful. Does FreeBSD have the 'ltrace' utility? If so, you could do $ ltrace bin/picolisp 2xxx : (ht:Prin 123) and then look into 'xxx' for something like dlopen(lib/ht, 257)= 0x011700f0 dlsym(0x011700f0, Prin)= 0x7fe3f3f9f222 I use 'gdb' in such cases to single-step through the program, but that's not what I would really recommend ;-) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: ACID tests
In which actual situations do you need to do dbSync - commit upd as opposed to just commit upd? It seems to me the RMDBS equivalent is begin - commit? If you do db, put and commit upd calls so that they happen roughly at the same time you should be as safe as you are when you do a update table set bla bla where userid = 5 in an RMDBS? Let's take what I actually do at work as an example, pretend that I would like to try to move the whole casino database from MySQL/InnoDB to PL, the main thing then would be the following SQL query for example: update users set balance = balance + 10 where user_id = 50. There can be 100 such calls per second and upwards 5 of them per second for the same user. Doing a dbSync here doesn't makes sense, there are no relations, just a number that needs increasing or decreasing, updating user 5's balance should not have to wait for an update of 10's balance to finish and so on. It seems to me that this situation is solved in PL by simply doing (commit upd)s without any dbSyncs, if there are several updates coming in at virtually the same time they will still be synced through the commit upds. Also I can NEVER put the balance but have to use dec and inc, just like in the RMDBS scenario, doing a set balance = 100 somewhere would be suicide, apart from that I should be ok I think? But the most common scenario though would simply be a (commit), ie we don't care who gets there first or not. On Sat, Jan 5, 2013 at 11:44 PM, Alexander Burger a...@software-lab.dewrote: On Sat, Jan 05, 2013 at 11:25:30PM +0700, Henrik Sarvell wrote: 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? Yes. Try it ;-) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
