I think you are right. perhaps the problem is session. Did you try
unlock it?
On Nov 11, 12:48 am, VP 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) concurrently. If
>- 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 11
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 wrote:
> Didn't think of this, but in fact I'm using sqlite, which seems to be
> a lot faster than postgreSQL.
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.
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 th
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 wrote:
> I do not think this is locking web2py. But there are two
> possibilities:
> - if you are usin
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
u
7 matches
Mail list logo
