Issue #838 resolved

RamSession leaks RLock objects if session.save() not called

Anonymous created an issue

I'm using !RamSessions with my CherryPy app and the most excellent Dowser has revealed to me that I am leaking RLocks. I followed through to the Trace page and it looks like the locks in question are ones stored in the !RamSession.locks dict.

The way I read the !RamSession.clean_up code, the lock will never be unreferenced from this dict unless I have first called save() at least once on the session (to put a key in the !RamSession.cache dict). Since I never call save() on my sessions (what's the point, with a !RamSession?), the locks persist forever.

I can change my code to call save(), which is probably nice in case I ever switch to a persistent session storage, but I thought I would point this behavior out since it could be considered to be a bug.

Reported by grib@billgribble.com

Comments (3)

  1. Nick Kamper

    The problem is that it appears that the save() function sets the expiration. Without the expiration being set, we don't know when to delete the session. The only way I could see it to be possible to purge old items without save()ing would be to set the expiration date within the locks.

    It seems that this would also create problems for functions such as _exists(), as it checks in self.cache as well.. This might cause problems with the if not self._exists() check on line 76. I'm not sure what kind of repercussions this would have.

  2. Nick Kamper

    If you want sessions to be cleaned up, you need to call save(). The main reason is that we *don't* know the expiration time until save() is called. It also makes your code more portable to other storage methods. I'm going to see about getting a note put into the documentation that save() must be called for RamSessions to be cleaned up.

  3. Log in to comment