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