Why not, but I really think that we should find a simple way to solve
the problems created by building multiple sessions or multiple
FieldStorage instances on the same request.
In the Java (i.e. servlets) world, when you want a session, you just
ask for it on the HttpRequest object. If a session exist, you get it,
if not, it is created. If you never ask for a session, then it is not
created, this way a session is not mandatory for pages which do not
require it.
I really think the current way of building Session instances in
mod_python is weird. First, because it opens a whole bunch of bugs due
to multiple Session instantiation (i.e. deadlocks). Second, because
the Session hosting infrastructure is up to the developer (which can
choose between MemorySession, DBMSession or FileSession) whereas I
think it should be up to the hoster.
The session infrastructure should be defined in httpd.conf or a
.htaccess file, with something like :
PythonOption SessionInstantiation "FileSession(directory='/tmp/sessions')"
Then, there would be a get_session() method on the request object,
that would check if a session is already present and if not would
execute the code defined in SessionInstantiation.
Something similar should be done with the form parsing mechanism.
Instantiating FieldStorage should be done my mod_python, not the
developer. The developer could then call req.get_uri_parameters() (all
the function names are of course subject to debate) to get the
parameters that were passed in the URI, req.get_form_parameters() to
get the parameters that were passed in a POST of content type
application/x-www-form-urlencoded, and req.get_combined_parameters()
for a combination of the two sets of parameters. Trying to read on the
request after a call to get_form_parameters() should raise an
exception, and conversely.
Solving these two problems would simplify a lot of code and could
please a lot of people, except from the fact that this would break
some compatibility with previous code :(.
I know there is a lot of shouldas and wouldas in this mail but I
really feel that some people who are used to other web frameworks can
be horrified by some very low level issues that they have to solve by
themselves. Other web frameworks are a little more helpful. Do we
really want developers to loose time thinking about whether the number
of times they already instantiated a Session object ?
Regards,
Nicolas
2005/5/20, Jim Gallacher <[EMAIL PROTECTED]>:
> I'm spending some time today to work on the Session docs, and was
> looking at the mod_python mail archives.
>
> It seems that users quite often deadlock their sessions, and eventually
> exhaust the max thread/processes available. The only way to kill the
> deadlocked sessions is by re-starting apache.
>
> What do people think of the idea of adding a function to _apache which
> would unlock all locked sessions do resolve deadlocks. If there is a
> least one thread/process available to handle the request then apache
> could be effectively restored without a restart. I know that this is not
> ideal, but it's better than killing the server altogether.
>
> Code might look something like this, hacked from _global_unlock:
>
> static PyObject *_global_emergency_unlock(PyObject *self, PyObject *args)
> {
>
> PyObject *server;
> PyObject *key;
> server_rec *s;
> py_global_config *glb;
> int index = 0;
> apr_status_t rv;
>
> if (! PyArg_ParseTuple(args, "OO|i", &server, &key, &index))
> return NULL;
>
> if (! MpServer_Check(server)) {
> PyErr_SetString(PyExc_TypeError,
> "First argument must be a server object");
> return NULL;
> }
>
> s = ((serverobject *)server)->server;
>
> apr_pool_userdata_get((void **)&glb, MP_CONFIG_KEY,
> s->process->pool);
>
> for (index = 0; index < glb->nlocks; index++) {
> apr_global_mutex_unlock(glb->g_locks[index]);
> }
>
> Py_INCREF(Py_None);
> return Py_None;
> }
>
> Just thinking out loud.
> Jim
>
