Just so everyone is clear, implementation of req.get_session() or its
equivalent has been deferred to version 3.3.
Graham Dumpleton wrote:
Some will know that I haven't been too keen on the way in which the
proposed new req.get_session() method was being implemented. My concerns
were that it was a magic box and didn't allow access to the underlying
variable holding the session object so as to allow checks such as
determining whether a session already existed before creating it. I also
had my concerns about how the session would be automatically unlocked
when req.internal_redirect() was used, something which may introduce
backward compatibility problems.
Anyway, have been thinking about this stuff on and off and have come
with an idea which might be worth pursuing.
Previously when discussing the issue of the "req" object not being
available to apache.import_module() unless explicitly provided, and the
implications of this as far as ensuring that settings for logging and
autoreload were consistent between code and Apache configuration files,
I proposed the idea of a request cache.
http://www.mail-archive.com/python-dev@httpd.apache.org/msg00197.html
This was where the request object was put in a globally accessible
dictionary indexed by thread identifier. Having been done, the request
object could be accessed from anywhere. There were various issues
related to use of req.internal_request() that had to be catered for,
but in short it acted like a thread specific global variable.
Now consider something similar for the instance of a session object
that is created. Ie.,
def Session(...):
Determine session id if not supplied as argument.
Check session object cache to see if session instance already
stored for (threadId,sessionId).
If cached session object exists, use it and return it.
Otherwise create new session object, store it in the cache under
the key (threadId,sessionId) and return it.
A cleanup handler is already registered for a session object when a
session object is created. This same cleanup handler can remove the
session object from the cache.
In respect of req.internal_redirect(), with the above there doesn't need
to be any special code which unlocks the session. Instead, when any code
executed as a consequence of req.internal_redirect() calls
Session.Session()
to create the session object, it will be given the already constructed
session object instead of creating a new one. The session lock will never
have been released and the code will simply use it. The code called by
req.internal_redirect() can save the session, or it could even be done
by the code which called req.internal_redirect() in the first place.
Because the session instance is stored in a global cache within the
session code and not in the request object itself, one can probably even
totally do away with the req.get_session() method. Code will simply
continue to use Session.Session() method and users can store it wherever
they like.
Well, thats the basic idea. It obviously needs a bit of work on the caching
with respect to thread locks etc, but that shouldn't be too much work.
Comments? Have I explained it well enough?
Graham
I think this may have merit although I need to mull it over.
Would the session cache be on disk or in memory? If in memory, what are
the implications in an mpm-prefork environment? If on disk, what are the
performance implications? Will it introduce new and exciting locking
issues for accessing the cache?
I'm not looking for answers to the above at this point, just recording
them for the record.
Jim
