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 <mdipie...@cs.depaul.edu> wrote: > windows, mac, linux. Can you reproduce this error with trunk? > > On Sep 8, 9:13 am, mdipierro <mdipie...@cs.depaul.edu> 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 <tfarr...@swgen.com> 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 web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
