Skip Menu |
 

This queue is for tickets about the AxKit-XSP-BasicSession CPAN distribution.

Report information
The Basics
Id: 12473
Status: stalled
Priority: 0/
Queue: AxKit-XSP-BasicSession

People
Owner: Nobody in particular
Requestors: kjetilk [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: Session can't untie properly when invalidated
Download (untitled) / with headers
text/plain 1.6k
This is the modules' maintainer documenting a bug that we're working on. It is a rather opaque issue, and so, it is hard to know when it'll be fixed. Therefore, it'll be useful for users and programmers to know exactly what's going wrong. Apache::Session works by tieing the object to a hash, and to invalidate a session, you call a delete method on the tied hash. To destroy the object, OTOH, you untie the hash. Due to locking issues for the database backends, one should really carefully destroy the object when you're finished with it. For some backends, it is not critical, for others it is. For this reason, BasicSession 0.22 will sort of work, with a few quirks, with DB_File without locking. For e.g. Postgres, it will run into issues it can't overcome. Those quirks are sufficiently annoying to devote attention to, so we've been working on this for a few days. The problem we now see is that the hash cannot be untied properly. The reason for this problem is documented on pages 395 to 397 of the Camel Book, so it is not that we don't understand the problem. We see that we attempt to untie at line 19: untie %session if (ref tied %session); In the case when the handler is called from the cleanup method (like it is in the recent developer versions, by necessity): We get a warning here: untie attempted while 1 inner references still exist That's the problem, we can't really see what references we have to the tied object. Therefore, we haven't found the solution. It probably has to do with the cleanup method calling the handler. Also, the %session hash is a global variable, perhaps it shouldn't be. That's how the issue stands right now. People are encouraged to chime in. Kjetil
I guess no-one's interested. I'm not running this anymore myself either.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.