you *shall* commit or rollback as frequently as possibile in your
parallel task. Otherwise you keep an open transaction that is likely
to lock the whole database.
2014-04-24 23:03 GMT+02:00 Manuele Pesenti manuele.pese...@gmail.com:
Il 24/04/14 21:03, Marin Pranjić ha scritto:
It might be that
let's clear things up.
a) as a general rule of thumb, one should commit() as soon as the
modifications issued to the backend are atomic and leave the state of the
database as consistent with the data model and the app code
b) the web2py web part commit()s at every end of a successful
I suggest not to keep open transactions for days in any case. Keeping
the state of the application in an uncommitted transaction is usually
sign of a bug easy to fix. Some ORM users do it without understanding
the implications. (I have experience of such bad designs in Hibernate
applications I
Hi!
I want to notify a strange behaviour. If I run any kind of parallel
command, such as calling web2py.py with -K option to run my scheduled
task or with -S app -M to test manually some function in my
environment it cause a portal block. The portal will reply again only
from the moment I kill the
It might be that database is blocking because you never end a transaction.
Do you have db.commit() in your task?
Marin
On Thu, Apr 24, 2014 at 8:58 PM, Manuele Pesenti
manuele.pese...@gmail.comwrote:
Hi!
I want to notify a strange behaviour. If I run any kind of parallel
command, such as
Il 24/04/14 21:03, Marin Pranjić ha scritto:
It might be that database is blocking because you never end a transaction.
Do you have db.commit() in your task?
Marin
Hi Marin,
thanks for you replay. The only commit explicitly called is inside a
scheduler function where afaik is necessary because
6 matches
Mail list logo
