Where is the database server running? Is it possible there are occasional 
network problems connecting to it?


On Monday, April 16, 2018 at 3:15:54 PM UTC-4, Lisandro wrote:
> Hi there, sorry to bother again, I have some additional info that could 
> help.
> The problem happened again, exactly the same as the other times. 
> But this time an error ticket was created with this traceback:
>    - 
>    Traceback (most recent call last):
>      File "/var/www/medios/gluon/main.py", line 463, in wsgibase
>        session._try_store_in_db(request, response)
>      File "/var/www/medios/gluon/globals.py", line 1152, in _try_store_in_db
>        if not table._db(table.id == record_id).update(**dd):
>      File "/var/www/medios/gluon/packages/dal/pydal/objects.py", line 2117, 
> in update
>        ret = db._adapter.update("%s" % table._tablename,self.query,fields)
>      File "/var/www/medios/gluon/packages/dal/pydal/adapters/base.py", line 
> 988, in update
>        raise e
>    DatabaseError: query_wait_timeout
>    server closed the connection unexpectedly
>        This probably means the server terminated abnormally
>        before or while processing the request.
> Could this indicate that for some reason web2py is failing to store the 
> session?
> Or could it still be that a deadlock in my app code is producing this 
> error?
> El viernes, 6 de abril de 2018, 18:59:28 (UTC-3), Lisandro escribió:
>> Oh, I see, you made a good point there, I hadn't realised.
>> I guess I will have to take a closer look to my app code. Considering 
>> that the problem exists in specific accounts while others work ok, and 
>> considering also that the problem happens with any request that that 
>> specific user makes to any controller/function, I'm thinking: what does my 
>> app do different for a user compared to another one at request level? For 
>> "request level" I mean all the code the app runs in every request, to 
>> start, the models/db.py
>> I'll take a closer look to that and will post another message here if I 
>> find something that could signal the root cause of the issue. 
>> Thank you very much for your help!
>> El viernes, 6 de abril de 2018, 16:05:13 (UTC-3), Anthony escribió:
>>> On Friday, April 6, 2018 at 10:58:56 AM UTC-4, Lisandro wrote:
>>>> Yes, in fact, I've been running that SQL command to check for locks, 
>>>> and sometimes I see that lock on other tables, but that other locks live 
>>>> for less than a second. However, when the problem happens, the lock on the 
>>>> auth_user and web2py_session tables remains there for the whole 60 seconds.
>>> Yes, but that doesn't mean the lock or the database has anything to do 
>>> with the app hanging. The locks will be held for the duration of the 
>>> database transaction, and web2py wraps HTTP requests in a transaction, so 
>>> the transaction doesn't end until the request ends (unless you explicitly 
>>> call db.commit()). In other words, the app is not hanging because the locks 
>>> are being held, but rather the locks are being held because the app is 
>>> hanging. First you have to figure out why the app is hanging (it could be 
>>> the database, but could be something else).
>>> Anthony

- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to