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