Session passivation (was: NullPointerException from HttpSessionFacade.invalidate())

[Kief Morris <ki...@bitbull.com>]

Craig R. McClanahan typed the following on 03:44 PM 1/14/2001 -0800
>"Christopher K. St. John" wrote:
>> >
>> > If your server implements session swapping or distribution (as we are 
>currently
>> > developing in the 4.1 repository), it is pretty much guaranteed that 
>different
>> > session object instances may be used during the lifetime of the same 
>session.
>> >
>>
>>  But don't you get session lifecycle events if that happens?
>
>Yes ... sessionWillPassivate() before the old session is removed, and
>sessionDidActivate() after the new one has been installed.

I hadn't thought about the issue of web apps keeping references to a session,
this underlines the concern I mentioned earlier about passivation events and
backing up sessions. If web app code depends on these events to tell it when
a session is being removed from memory, then they shouldn't be fired when
a session is just being backed up to a Store. But these may be needed for
pre/post passivation/activation cleanup tasks.

I may send a message to the api feedback address to get clarification on the 
spec. Namely:

- Is it OK for the container to keep multiple copies of a session in a distributed 
  web application? The spec doesn't say no, although it does say that only one
  instance of the app should be handling requests for a session at a time, which
  implies you could have multiple copies if you have a locking mechanism and
  maintain data consistency.

- If it is OK, should the container send activation/passivation events when a
  session is being serialized (or whatever) for replication purposes? Whatever
  the answer is, it would be nice if the spec clarified it explicitly so webapp
  developers can depend on it being consistent on different containers.

This also raises a Catalina issue I forgot to mention in the message with my
PersistentManager patches. Currently there isn't any way (that I could see)
to tell when a request has finished handling a session. It's possible that my
persistence code could swap a session out while it's being used in a request.

I'm not sure what the best way is to handle this. Possibly ContainerBase.invoke()
could make a call to a new method in the Manager interface after the valves
have all been invoked? Something like:

    public void invoke(Request request, Response response)
	throws IOException, ServletException {

	if (first != null)
	    first.invoke(request, response);
	else if (basic != null)
	    basic.invoke(request, response);
	else
	    throw new IllegalStateException
		(sm.getString("containerBase.notConfigured"));

+         if (manager != null && request.getSession(false) != null)
+	    manager.releaseSession(request.getSession());
    }

Then the manager can enforce a locking mechanism on the session.

Kief

Re: Session passivation (was: NullPointerException fromHttpSessionFacade.invalidate())

[Kief Morris <ki...@bitbull.com>]

I typed the following on 03:10 PM 1/15/2001 -0500
>If Manager.releaseSession() method is implemented (I don't really like that 
>method name though), then StandardSession.expire() and invalidate() should
>call it, and maybe some other places. 

Doh, actually the locking would probably be implemented in the StandardSession
class itself, so there wouldn't be any need to call the Manager.releaseSession().

Kief

Re: Session passivation (was: NullPointerException fromHttpSessionFacade.invalidate())

[Kief Morris <ki...@bitbull.com>]

Craig R. McClanahan typed the following on 11:42 AM 1/15/2001 -0800

>> - If it is OK, should the container send activation/passivation events when a
>>   session is being serialized (or whatever) for replication purposes? 
>
>The following comment is in the Javadocs at the top of
>javax.servlet.http.HttpSessionActivationListener (the interface that defines 
>the
>passivate and activate listener methods):
>
>    A container that migrates sessions between VMs or
>    persists sessions is required to notify all attributes
>    bound to sessions implementing HttpSessionActivationListener.

OK, so it's clear that the activation events are appropriate only when
the session is actually being removed from a JVM. What I'm trying
to understand is whether a web app developer can ensure that they
get the chance to muck with an object used as a session attribute
before and after it is copied to a Store for backup. The spec says
the serialization events is not necessarily called by the container, so 
it seems the answer to this question is: no.

>> This also raises a Catalina issue I forgot to mention in the message with my
>> PersistentManager patches. Currently there isn't any way (that I could see)
>> to tell when a request has finished handling a session. It's possible that my
>> persistence code could swap a session out while it's being used in a request.
>>
>
>No, there isn't :-(.  We need a registration mechanism a request can call 
>that says "I
>am currently using this session" and "I am done using this session."

Ok, but the request doesn't have any way to know when this kind of
thing happens, so it can be done by the session itself.

>> +         if (manager != null && request.getSession(false) != null)
>> +           manager.releaseSession(request.getSession());
>>     }
>
>There is the possibility of referencing more than one session in the same 
>request, in
>at least a couple of circumstances:
>
>* The originally requested session is no longer valid,
>  and a new one is created.
>
>* The currently valid session is invalidated, and a
>  new one is created.
>
>so any registration/locking mechanism needs to deal with this correctly.

If Manager.releaseSession() method is implemented (I don't really like that 
method name though), then StandardSession.expire() and invalidate() should
call it, and maybe some other places. 

I'm not sure about the originally requested session being invalid: the findSession()
method of the Manager should know about this when it hands it out - *should* it
return an invalid session? Would it be wrong for findSession() to check whether
the session is valid and return null or a new session if so? 

>>
>> Kief
>>
>
>Craig
>

Kief

Re: one session for many web sites

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 14 May 2001, Mihai Popoaei wrote:

> 
> Hello,
> 
> How can I have the same session for many web sites?
> 
> By default, for the first request tomcat creates a implicit session and
> sends a cookie with domain=servername. What I wanna do is setting this
> cookie for domain=partian domain name (like .kiki.ro) (that means this
> cookie will come back for all the hosts ending with .kiki.ro and I'll have
> the same session for all the sites :)). I think I have to say that I use
> the same application context for all this sites...
> 
> Another problem is using the same session between applications... I know
> it is not conform the sun specifications (... HttpSession objects must be 
> scoped at the application / servlet context level. The underlying
> mechanism, such as the cookie used to establish the session, can be shared
> between contexts, but the object exposed, and more importantly the
> attributes in that object, must not be shared between contexts. ...),
> but there must be a way to do that...
> 

You are perfectly free to "roll your own" session implementation that
meets your needs (cross-host and cross-webapp).  However, the standard
APis don't support these uses, so this will definitely be an application
specific (and probably Tomcat-specific) approach.

When you try this, you'll discover that having a cookie recognized
correctly is the least of your problems.  You'll also need to ensure that
all of the classes are loaded from a shared class loader -- classes that
are loaded from one web-app's /WEB-INF/classes or /WEB-INF/lib directory
are not visible to any other web-app.

> 
> thx,
>  --
> :], Mihai P.
> 
Craig

Re: one session for many web sites

[Mihai Popoaei <xb...@is.necomm.ro>]

On Mon, 14 May 2001 cmanolache@yahoo.com wrote:

> Salut Mihai,
	Salut.
> 
> > How can I have the same session for many web sites?
> > 
> > By default, for the first request tomcat creates a implicit session and
> > sends a cookie with domain=servername. What I wanna do is setting this
> > cookie for domain=partian domain name (like .kiki.ro) (that means this
> > cookie will come back for all the hosts ending with .kiki.ro and I'll have
> > the same session for all the sites :)). I think I have to say that I use
> > the same application context for all this sites...
> > 
> > Another problem is using the same session between applications... I know
> > it is not conform the sun specifications (... HttpSession objects must be 
> > scoped at the application / servlet context level. The underlying
> > mechanism, such as the cookie used to establish the session, can be shared
> > between contexts, but the object exposed, and more importantly the
> > attributes in that object, must not be shared between contexts. ...),
> > but there must be a way to do that...
> 
> 
> As long as you know this is not standard :-), you will have to make some
> changes to the session interceptor or create a new one.

"Cross-webapps" sessions are not standard, but for "cross-host" sessions I
didn't find any specifications...

> In 3.3, the code is in modules.session.SessionId, you should probably 
> create a new module, add an option and code that supports what you
> need, and maybe publish the changes for others :-)

I taked a look into the sources and I didn't find any code that sets the
domain for JSESSIONID cookie... I don't know exactly what's going on, but 
I imagine that mod_jk or apache sets this (the domain) if it is not 
specified... Am I right?

 Thx again...

> I don't think this can be commited in jakarta-tomcat, as it is not
> standard and it's not a required feature, but it would be nice to have it
> somewhere.
> 
> 
> Costin
> 
> > 
> > 
> > thx,
> >  --
> > :], Mihai P.
> > 
> > xblue@
> >  necomm.ro
> >  fenrir.infoiasi.ro
> > 
> > icq:77484853
> > 
> > =====-----=====
> > 
> 

-- 
:], Mihai P.

xblue@
 necomm.ro
 fenrir.infoiasi.ro

icq:77484853

=====-----=====

Re: one session for many web sites

[cm...@yahoo.com]

Salut Mihai,

> How can I have the same session for many web sites?
> 
> By default, for the first request tomcat creates a implicit session and
> sends a cookie with domain=servername. What I wanna do is setting this
> cookie for domain=partian domain name (like .kiki.ro) (that means this
> cookie will come back for all the hosts ending with .kiki.ro and I'll have
> the same session for all the sites :)). I think I have to say that I use
> the same application context for all this sites...
> 
> Another problem is using the same session between applications... I know
> it is not conform the sun specifications (... HttpSession objects must be 
> scoped at the application / servlet context level. The underlying
> mechanism, such as the cookie used to establish the session, can be shared
> between contexts, but the object exposed, and more importantly the
> attributes in that object, must not be shared between contexts. ...),
> but there must be a way to do that...


As long as you know this is not standard :-), you will have to make some
changes to the session interceptor or create a new one.

In 3.3, the code is in modules.session.SessionId, you should probably 
create a new module, add an option and code that supports what you
need, and maybe publish the changes for others :-)

I don't think this can be commited in jakarta-tomcat, as it is not
standard and it's not a required feature, but it would be nice to have it
somewhere.


Costin

> 
> 
> thx,
>  --
> :], Mihai P.
> 
> xblue@
>  necomm.ro
>  fenrir.infoiasi.ro
> 
> icq:77484853
> 
> =====-----=====
> 

one session for many web sites

[Mihai Popoaei <xb...@is.necomm.ro>]

Hello,

How can I have the same session for many web sites?

By default, for the first request tomcat creates a implicit session and
sends a cookie with domain=servername. What I wanna do is setting this
cookie for domain=partian domain name (like .kiki.ro) (that means this
cookie will come back for all the hosts ending with .kiki.ro and I'll have
the same session for all the sites :)). I think I have to say that I use
the same application context for all this sites...

Another problem is using the same session between applications... I know
it is not conform the sun specifications (... HttpSession objects must be 
scoped at the application / servlet context level. The underlying
mechanism, such as the cookie used to establish the session, can be shared
between contexts, but the object exposed, and more importantly the
attributes in that object, must not be shared between contexts. ...),
but there must be a way to do that...


thx,
 --
:], Mihai P.

xblue@
 necomm.ro
 fenrir.infoiasi.ro

icq:77484853

=====-----=====

Re: Session passivation (was: NullPointerException fromHttpSessionFacade.invalidate())

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Kief Morris wrote:

> Craig R. McClanahan typed the following on 03:44 PM 1/14/2001 -0800
> >"Christopher K. St. John" wrote:
> >> >
> >> > If your server implements session swapping or distribution (as we are
> >currently
> >> > developing in the 4.1 repository), it is pretty much guaranteed that
> >different
> >> > session object instances may be used during the lifetime of the same
> >session.
> >> >
> >>
> >>  But don't you get session lifecycle events if that happens?
> >
> >Yes ... sessionWillPassivate() before the old session is removed, and
> >sessionDidActivate() after the new one has been installed.
>
> I hadn't thought about the issue of web apps keeping references to a session,
> this underlines the concern I mentioned earlier about passivation events and
> backing up sessions. If web app code depends on these events to tell it when
> a session is being removed from memory, then they shouldn't be fired when
> a session is just being backed up to a Store. But these may be needed for
> pre/post passivation/activation cleanup tasks.
>

IMHO the answer is yes ... passivation to the Store means that the container is
releasing all it's references to the session instance currently in use, and any future
reference to this session will cause it to be reactivated (possibly in the same JVM,
possibly in a different one), but with a new object instance.  The activation event
will allow any interested listeners to update their references.

The passivation/activation lifecycle here is very similar to what happens with EJBs,
for the same reasons.

>
> I may send a message to the api feedback address to get clarification on the
> spec. Namely:
>
> - Is it OK for the container to keep multiple copies of a session in a distributed
>   web application? The spec doesn't say no, although it does say that only one
>   instance of the app should be handling requests for a session at a time, which
>   implies you could have multiple copies if you have a locking mechanism and
>   maintain data consistency.
>

Some containers do this (I think iPlanet does?) to support hot failover.  I don't see
any spec prohibition to this, as long as you obey the part about request processing
all being within one JVM at any one point in time.

>
> - If it is OK, should the container send activation/passivation events when a
>   session is being serialized (or whatever) for replication purposes? Whatever
>   the answer is, it would be nice if the spec clarified it explicitly so webapp
>   developers can depend on it being consistent on different containers.
>

The following comment is in the Javadocs at the top of
javax.servlet.http.HttpSessionActivationListener (the interface that defines the
passivate and activate listener methods):

    A container that migrates sessions between VMs or
    persists sessions is required to notify all attributes
    bound to sessions implementing HttpSessionActivationListener.

That seems pretty clear to me ... is it missing something?

>
> This also raises a Catalina issue I forgot to mention in the message with my
> PersistentManager patches. Currently there isn't any way (that I could see)
> to tell when a request has finished handling a session. It's possible that my
> persistence code could swap a session out while it's being used in a request.
>

No, there isn't :-(.  We need a registration mechanism a request can call that says "I
am currently using this session" and "I am done using this session."

>
> I'm not sure what the best way is to handle this. Possibly ContainerBase.invoke()
> could make a call to a new method in the Manager interface after the valves
> have all been invoked? Something like:
>
>     public void invoke(Request request, Response response)
>         throws IOException, ServletException {
>
>         if (first != null)
>             first.invoke(request, response);
>         else if (basic != null)
>             basic.invoke(request, response);
>         else
>             throw new IllegalStateException
>                 (sm.getString("containerBase.notConfigured"));
>
> +         if (manager != null && request.getSession(false) != null)
> +           manager.releaseSession(request.getSession());
>     }
>
> Then the manager can enforce a locking mechanism on the session.
>

There is the possibility of referencing more than one session in the same request, in
at least a couple of circumstances:

* The originally requested session is no longer valid,
  and a new one is created.

* The currently valid session is invalidated, and a
  new one is created.

so any registration/locking mechanism needs to deal with this correctly.

>
> Kief
>

Craig