Ticket #475 (defect)
Opened 3 years ago
Last modified 2 years ago
double calling acquire_lock() freezes the request
Status: closed (fixed)
| Reported by: | anonymous | Assigned to: | rdelon |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | CherryPy code | Keywords: | sessionfilter |
| Cc: |
Calling cherrypy.session.acquire_lock() twice (even from within the same method body) freezes the request processing. This is particulary important in complex environments (filters, decorators) when the possibility to call acquire_lock() more than once is high.
Change History
02/23/06 09:05:33: Modified by fumanchu
02/24/06 02:30:16: Modified by mic
To be more precise - this bug came out while using file sessions not the RAM ones. But anyway switching to RLock object didn't help.
02/28/06 07:55:12: Modified by rdelon
- status changed from new to closed.
- resolution set to invalid.
You're not supposed to call acquire_lock twice.
03/01/06 03:14:33: Modified by mic
- status changed from closed to reopened.
- resolution deleted.
I don't think that shortcomings of the application can be solved by such prohibition. If we treat CP as the base for the frameworks and enterprise-level applications (I do!) there are many situations when such limit is unacceptable. Let's simply say that developer uses some third-party filters or decorators that implicitly call acquire_lock() and also repeats this operation myself...
04/01/06 05:11:33: Modified by lawouach
While I do understand your point mic, if you are in enterprise environment you are supposed to document everything right? So an external piece of code should state that it acquires the lock. That does not solve your issue here but you are supposed to be responsible for some things as well and you can't let CherryPy runs the whole World.
CherryPy is not a framework that tries to do what a responsible developer should do. CherryPy is a simple library.
04/04/06 04:52:05: Modified by mic
In the meanwhile I realized that it all can be solved by simply setting session management to 'implicit' (I still don't understand why it's not the default one). I think we can close this one - but this subject definitely needs better, pattern-oriented documentation.
06/25/06 23:16:21: Modified by fumanchu
- status changed from reopened to closed.
- resolution set to fixed.
Fixed for file sessions in [1162].
12/09/06 17:37:48: Modified by fumanchu
Fixed in 2.x for file session in [1501].
Looks like the RAM session manager should use a threading.RLock instead of a Lock.