I do not think this is locking web2py. But there are two
possibilities:
- if you are using sqlite, the database is locked (sqlite cannot be
accessed concurrently)
- the user session is locked. This means the user who called the long
running process cannot access other actions until his session is
Anyway...
a background process may be a better solution (no session problem but
you may still have sqlite lock unless you db.commit() manually after
each update).
On Nov 10, 11:57 pm, mdipierro mdipie...@cs.depaul.edu wrote:
I do not think this is locking web2py. But there are two
Didn't think of this, but in fact I'm using sqlite, which seems to be
a lot faster than postgreSQL. However, the controller function that
i called does not touch the database. So unless web2py opens the
database and kind of leaves it there, it shouldn't happen (right?).
Another behavior is
Session locking is the problem.
session._unlock(response) seems to fix this.
But i'll consider the background process option (as of now , it's more
convenient for me this way).
Thanks.
web2py opens it anyway because it is in the model.
You can force a release
DAL.close_all_instances(DAL.commit)
at the beginning of your long action. should work
On Nov 11, 12:12 am, VP vtp2...@gmail.com wrote:
Didn't think of this, but in fact I'm using sqlite, which seems to be
a lot faster
- if you are using sqlite, the database is locked (sqlite cannot be
accessed concurrently)
Is this true?
I thought sqlite db's can be read (but not written) concurrently. If
so, then even if web2py opens it, and as long as there's no write
access, things still should be fine. Right?
On Nov
I think you are right. perhaps the problem is session. Did you try
unlock it?
On Nov 11, 12:48 am, VP vtp2...@gmail.com wrote:
- if you are using sqlite, the database is locked (sqlite cannot be
accessed concurrently)
Is this true?
I thought sqlite db's can be read (but not written)
7 matches
Mail list logo
