maintaining sessions among multiple processes

[martin nylin <ma...@gmail.com>]

hi

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 and would therefore like all
incoming request from a certain user to always be dispatched to the
same process. in other words: if we have recently received a request
from the same user, then dispatch the current request to the same
process as we used for the previous request.

i do realize that shared memory might be an alternative way to
implement sessions, but i think it would be very tricky in this case
since my session objects contains pointers to objects of unknown size

/martin

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

Re: maintaining sessions among multiple processes

[Jim Jagielski <ji...@jaguNET.com>]

On Oct 2, 2009, at 7:52 AM, martin nylin wrote:

> hi
>
> 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 and would therefore like all
> incoming request from a certain user to always be dispatched to the
> same process. in other words: if we have recently received a request
> from the same user, then dispatch the current request to the same
> process as we used for the previous request.
>
> i do realize that shared memory might be an alternative way to
> implement sessions, but i think it would be very tricky in this case
> since my session objects contains pointers to objects of unknown size
>

It sounds like you simply need to use an external session storage
mechanism, like memcached or db4 or something else... This is esp
true if you need to horizontally scale as well.

Re: maintaining sessions among multiple processes

[jo...@joe-lewis.com]

> On Fri, Oct 2, 2009 at 2:16 PM, Nick Kew <ni...@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
>

Most session management is implemented in a higher layer (the application
such as PHP or Java's Hibernate).  It is possible and has been
implemented.

Under the caveats you later write, using r->user is not fine for a session
token.  Until the user has authenticated, that data wouldn't be available
in the authenticated session.  You would have to use cookies as session
managers.  Apache 2.3 has mod_session.  You might want to take a look at
the code.

If you must reinvent the wheel, it may be simpler to use mod_unique_id. 
Since mod_unique_id generates a different ID for each request (not across
all requests by the same session), you would check to see if the browser
cookie is there, and if not, copy it from mod_unique_id for your session
key, and send the cookie to the browser.  Your session will have been
started, and the cookie will be available across all subsequent requests,
giving you what you need.  Your apache source components used are
r->headers_in and r->headers_out .

Joe

Re: maintaining sessions among multiple processes

[martin nylin <ma...@gmail.com>]

yes, serialization would indeed solve my problem and give me several
options for storing session data on the server side (or even send the
session object back and forth to the client in cookies). BUT, i think
that in order to serialize an object you have to know its true type.
what i'm trying to do is a framework that is very similar to java
servlets, but for c++. consider the HttpSession class in java, it has
a method like this:

void 	setAttribute(java.lang.String name, java.lang.Object value)

using c++ that would be something like this:

void 	setAttribute(const std::string& name, void* value)

now, when implementing the setAttribute method comes the tricky part:
you have been passed an object that has been cast to void* and to my
knowledge there is no way to determine its true type or size. there
lies my problem.

/martin

On Sun, Oct 4, 2009 at 3:22 AM, Yoichi Kawasaki <yo...@gmail.com> wrote:
>>
>> 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.
>>
>
> why don't you serizlie the session objects and store them in rdmbs,
> memcached, etc?
> I use the term "seralize" and "deserialize" to mean the deconstruction
> of "sessionObject"
> to  a sequence of bytes, and reverse construction from a sequece of
> bytes to "sessionObject"
> respectively.
> for serialization, you can use any famouse libraries like
> "boost::serialization"
> or create a converter that can achive this kind of thing by yourself
> if the structure of
> "sessionObject" is simple enough.
>
> Yoichi
>
> --
> Yoichi Kawasaki <yo...@gmail.com>
>



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

Re: maintaining sessions among multiple processes

[Yoichi Kawasaki <yo...@gmail.com>]

>
> 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.
>

why don't you serizlie the session objects and store them in rdmbs,
memcached, etc?
I use the term "seralize" and "deserialize" to mean the deconstruction
of "sessionObject"
to  a sequence of bytes, and reverse construction from a sequece of
bytes to "sessionObject"
respectively.
for serialization, you can use any famouse libraries like
"boost::serialization"
or create a converter that can achive this kind of thing by yourself
if the structure of
"sessionObject" is simple enough.

Yoichi

-- 
Yoichi Kawasaki <yo...@gmail.com>

Re: maintaining sessions among multiple processes

[martin nylin <ma...@gmail.com>]

On Fri, Oct 2, 2009 at 2:16 PM, Nick Kew <ni...@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

Re: maintaining sessions among multiple processes

[Nick Kew <ni...@apache.org>]

martin nylin wrote:
> hi
> 
> 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.

>	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.

> i do realize that shared memory might be an alternative way to
> implement sessions, but i think it would be very tricky in this case
> since my session objects contains pointers to objects of unknown size

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.


-- 
Nick Kew