I often received that error with sqlite when the server was under heavy load. My fix was to change to postgres.
Richard On Sep 9, 1:00 am, Timbo <[email protected]> wrote: > Windows - source build previous version was 1.46 I think. I use > sqlite for everything (that the DAL talks to anyway) but since these > errors run in tandem, It seems that this may be how sessions are > implemented. It's a little weird because I'm not using database-based > sessions but rather file-based sessions. > > This only happens in my production environment. I'm not about to > checkout trunk and run it as production but as I said, I have made the > predescribed change to my production code. I'll let you know if I > still have issues. > > -tim > > On Sep 8, 9:22 am, mdipierro <[email protected]> wrote: > > > windows, mac, linux. Can you reproduce this error with trunk? > > > On Sep 8, 9:13 am, mdipierro <[email protected]> wrote: > > > > The change you suggest is already in trunk. > > > > About the first error. Which database are you using? Which is the > > > previous version you were using? > > > > On Sep 8, 9:08 am, Timbo <[email protected]> wrote: > > > > > Since upgrading to the new version, I'm getting this error about once > > > > daily: > > > > > Traceback (most recent call last): > > > > File "C:\web2py\gluon\main.py", line 405, in wsgibase > > > > SQLDB.close_all_instances(SQLDB.commit) > > > > File "C:\web2py\gluon\sql.py", line 594, in close_all_instances > > > > action(instance) > > > > File "C:\web2py\gluon\sql.py", line 1020, in commit > > > > self._connection.commit() > > > > OperationalError: database is locked > > > > > Getting this results in an unpleasant experience for my users I'm > > > > sure. I think this is for sessions which I use to set stuff on login > > > > and never change until they logout. Also this error seems to run in > > > > tandem with: > > > > > Traceback (most recent call last): > > > > File "C:\web2py\gluon\main.py", line 412, in wsgibase > > > > session._try_store_on_disk(request, response) > > > > File "C:\web2py\gluon\globals.py", line 366, in _try_store_on_disk > > > > self._unlock(response) > > > > File "C:\web2py\gluon\globals.py", line 374, in _unlock > > > > response.session_file.close() > > > > IOError: [Errno 13] Permission denied > > > > > If you look at globals.unlock(), it looks like this: > > > > > def _unlock(self, response): > > > > if response and response.session_file: > > > > try: > > > > portalocker.unlock(response.session_file) > > > > except ValueError: > > > > pass > > > > response.session_file.close() > > > > del response.session_file > > > > > Why do we allow the lock release to fail but still try to close the > > > > file? Is this related? In the meantime, I'm just going to move the > > > > last two lines into the try block. > > > > > Thanks, > > > > -tim > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
