I actually get an error using your trick:
Traceback (most recent call last):
File "gluon/scheduler.py", line 1512, in
main()
File "gluon/scheduler.py", line 1506, in main
utc_time=options.utc_time)
File "gluon/scheduler.py", line 588, in __init__
self.define_tables(db, migrate=m
in my environment, I can't see any idle in transaction that's why I
patched the scheduler and asked to do that test.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (
idle connection are one thing and they can be fine.
idle in transaction, usually happens when there is a missing commit and the
transaction stays open, delivering all sorts of locking over the long term
usually a commit or rollback before the fork should solve the problem.
2015-02-18 23:09 GMT+01:
uhm^3. The code is quite unfixable as it is (launching scheduler with
web2py.py -K appname). Remember that the only thing I'm trying to fix is
the main process using idle connections to all databases defined in the
models of you app.
However, there's a small unknown trick: the scheduler can be
uhm, the problem is more subtle.
The main process of the scheduler is like a shell opened on that
application... it needs to reads models to see the scheduler
definition. I guess that this means that it will also connect to all the
databases defined in models, even if it will effec
5 matches
Mail list logo
