On Mon, Jun 18, 2012 at 4:02 AM, Niphlod <niph...@gmail.com> wrote:
>> Ok, just to double check, that is for all DB back-ends or just for SQLite?
>>
> This is true for every backend.
Thanks!
> Web2py is not blocked, and again, it's only with SQLite that there is the
> problem. From the first update on the queue to the commit, no-one can access
> a SQLite database, hence an app trying to read from that will "hang".
> Anyway, in the "sleeping" loop, no modifications to the db are made so also
> with SQLite there will be no problems.
Ok. I was just about ready to believe that, but as per the link
Anthony sent (see my separate reply just sent), depending on whether
or not SQLite is in autocommit mode, doing a SELECT (query) could
cause it to take a SHARED lock which, while held, would block other
processes from acquiring the locks needed to update. That is, the
server script, just by looking for work and then sleeping, would lock
out any updates. But that depends on the mode of access (autocommit or
not)...
>> (I'm beginning to think that The Book should just say: This example is
>> for any DB except SQLite, don't use SQLite for this kind of processing
>> ???)
> Yep, I'll be fine with it ;-D
I was being half kidding, but only half. :-)
> Maybe I should make a slice on how to fix this behaviour also for
> SQLite..... it's just a bit complicated because it requires to rebuild the
> sqlite module with an updated library.
Oh, that's unfortunate. I have to say, I having the SQLite as part of
Python (i.e. not rebuilding) is a huge win for getting new user's into
the early success that makes them (or at least me) happy to keep using
and expanding their Web2py usage. :-)
Thanks,
--Doug
