httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From martin nylin <martin.ny...@gmail.com>
Subject Re: maintaining sessions among multiple processes
Date Sat, 03 Oct 2009 11:00:40 GMT
On Fri, Oct 2, 2009 at 2:16 PM, Nick Kew <niq@apache.org> wrote:
>> i'm using apache 2.2 mpm-worker and have noticed that incoming
>> requests are dispatched to apache processes in a way that makes it
>> hard for me to maintain sessions in my module. i'm using the user
>> field of the request_rec as session key
>
> Huh?  The request_rec has the lifetime of a request.  Nothing on
> it will preserve a session across requests.

i agree, but if the application has one session per user and all users
are authenticated, then the user field of the request rec works fine
as session token

>>  and would therefore like all
>> incoming request from a certain user to always be dispatched to the
>> same process.
>
> "from a certain user"?
>
> If you have a notion of user, then you have a session already!
> But you only know that mid-request.

yes, and that is my problem. i would like to access session data that
was stored by the application when processing earlier requests within
the same session. if there would have been only one worker process (or
if all requests belonging to the same session always were dispatched
to the same process) the problem could have been resolved like this:

//storing session data
apr_pool_userdata_set(sessionObject, r->user, apr_pool_cleanup_null,
r->server->process->pool);

//retrieving session data
apr_pool_userdata_get((void**)&sessionObject, r->user,r->server->process->pool);

but this does not work out for two reasons:
1) there is no global pool, ie a pool that is accessible from all
worker processes.
2) the sessionObject may contain objects that are allocated in process
local memory, ie not shared memory

> There are many ways to implement sessions: my book might help
> as might many of those that teach you development with Perl,
> PHP, Ruby, etc.  The usual way is to give the client a token,
> and you can match that to a serverside session token if it
> needs to record more state info than is reasonable client-side.

i find your book to be one of the most enlightening ones written in
recent years, but i haven't found the answers to my question in there.
the closest you get to touching the subject is perhaps the section on
"session management with SQL", which as jim jagielski also points out,
might be the way forward. it's just that my session objects contains
objects of unknown types so i don't know how to store them in a
traditional rdbms. maybe i can figure out a way to convert them to
blobs if you tell me that there is no way to do what i originally
suggested: interfere with the request dispatching in apache.

/martin


-- 
"A Catholic is more capable of evil than anyone"
Graham Greene

Mime
View raw message