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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
