Wow, this is a lot to digest. I'll attempt, but we may want to deal
with these one by one...
On Feb 28, 2006, at 3:03 AM, Greg Wilkins wrote:
Responding to this a bit late....
I like the concept of a Session API that can hide
all the variations of session implementations from the web container.
Instead of having different session managers for the different
clustering mechanisms, I'd like to have one session manager
written to this API that receives a Locator implementation and
everything else is hidden from it.
This API looks like a good start, but I think it is missing lots
that I'll need to write a jetty session manager that is based on
it:
ID Management
=============
Firstly, the API represents a flat session ID space and
I'm not sure that is sufficient. With cross context
dispatch you may have several different web sessions that
share the same ID. Also, EJB sessions may share that
ID and may be at different locations to the web session.
The idea was to build the simplest API that could preform. We tried
to leave complex session constructs out of the API. James and I did
talk about some of this stuff and thought we could simply build a
complex string to lookup the session data in the flat map.
So I think the API needs some more capabilities for
session ID management. Specifically the following questions
needs to be asked and answered:
+ Does session ID x exist in the whole server/cluster)
You always know every session that exists in the cluster:
locator.getSessionLocation(x)
+ Does session ID x exist for context y
In this case, I would say you lookup the session "x" and then see if
it has an entry for context "y"
+ get WEB session with ID x for context y
No idea what that means
+ invalidate ALL sessions with ID x
SessionLocation.destroy()
+ passivate ALL sessions (suspending node)
That would happen under the covers of the session API (i.e.,
implementation specific)
+ invalidate ALL sessions (shutting down)
Implementation specific
Now the above could be modelled with deep structure for the
state associated with an ID, but not if all state for an ID
has to be in one location.
Having all of the state for a single session located on a single
machine is a design assumption. We felt that if you wanted to let
the data be divided across several machines it was not a single
session session.
Session Management
==================
There is nothing in the API to help with session management.
Specifically:
+ last access time
+ access session (without actually modify state)
+ invalidate session
+ session timeouts
+ session events (eg session invalidation, passivation etc.)
Other than last access time, I would classify this as implementation
specific. The goal was to create a very very simply API that
OpenEJB, ServiceMix, Lingo, Tuscany and web containers could use
without haveing to know the internal details of the implementation.
Does you code specifically need this or it is a nice to have? If it
is the former, can you be a lot more specic on what the terms above
mean (I'm not a web expert) :)
Locking
=======
I'm also not sure about the semantics of release(). If I'm
writing a session manager, I'm not sure if I should be making
the decision of when to release - that is very much implementation
dependent. Some will replicate/sync on a setState, others will
do it at the end of every request, other will do it every n seconds
others will do it when the session is idle (has no requests).
Instead of commanding "release", perhaps the API should allow
the concept of a thread entering and existing a session scope:
runInSessionScope(Runnable doSomething
or
enterSessionScope()
leaveSessionScope()
individual implementations can decide what locking they
implement behind the scenes.
That is exactly how the API works. When you start using a session
you need to acquire it using the Locator and when you are done using
it, you release it. This is reference counting, and when the count
reaches zero we are in a stable state and can replicate. Here is a
test case that shows normal usage:
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
test/org/apache/geronimo/session/SessionTest.java
Policy
======
The SessionLocation interface has the start of a policy
API for managing session location. Cool, but I don't
want the web SessionManager to have to implement policy.
I don't want to have to call moveLocally() - I want something
else to have called that before the request comes near
the web containers session manager.
So I think the API needs to have the concept of a Policy
implementation that can be invoked before and after a
session is accessed.
I'm not sure exactly what you are looking for, but the following test
case shows the usage of move, redirect or proxy policies.
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
test/org/apache/geronimo/session/remote/RemoteSessionTest.java
We could add an API for making this decision, but I think the
decision policy is very specific to the client. For example, in EJB
you normally have a smart client, so the default policy is should be
clien side redirect.
Meta Data
=========
To implement a policy, we are going to need to implement
some meta data channelling. For example, if we are running
in the scenario where requests can be proxied to where a
session lives - we might want to have a policy that if
a session sees lots of requests being proxied from a
specific node (load balancer changed?) then that session
might want to move itself to that node.
Assuming we do add an interface to make the decision, I would hope
that all of these details would be implementation specific (i.e.,
under the covers of a very simple interface).
So firstly we need SessionLocatoin.moveto(Server server),
I'm confused. Why would we need that?
but more importantly, when we are redirecting or proxying
requests, it would be good to be able to attach impl
specific meta data to those requests. So the HTTP tier
needs to be able to ask a SessionLocation for an opaque
blob of meta data associated with a request and to be
able to set that meta data when it recieves it.
Huh? Redirect would be dependent on the web container so this would
be a detail for the web container to deal with. The session apis,
only says, "the session data is on server x". How the web container
gets the request to server x is it's problem.
I guess the nodes could communicate that meta data via
out-of-band paths, but then you are in a world of synchronization
pain - specially if the cluster grows, shrinks or changes.
I'm really confused now. I don't know why you would need any kind of
out-of-band meta data. The session apis are designed around the
concept of movable locks. In a moveable lock system, you only need
to know where the lock is located. If it is on your local machine
you just grab the lock. If it is remote, you can either move the
lock to the lock request, or move the lock request to the lock.
There should be no need for extra metadata, and the system should
scale very well.
Anyway, very soon, I'd like to start on the jetty6 geronimo
modules. So perhaps a way to turn these negative comments into
I didn't take these negatively at all. You are stating to look at
these from a user's perspective and there will always be confusion,
missing features and problems in new APIs.
positive suggestions is if I try to use the jetty6 module to
implement a session manager based on this API and then make changes
to make it work.
I would prefer that we discuss the API changes first. There are many
uses for this API and I want to keep them simple and avoid making
them to servlet centric. I think if we carefully work out the APIs
we can have something that works well for all of the users (i.e.,
OpenEJB, ServiceMix, Lingo, Tuscany and web containers) and the
implementers (i.e., WADI, ehCache, java.util.HashMap, TangoSol,
ObjectGrid).
-dain
