geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Wed, 01 Mar 2006 19:32:08 GMT
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:


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


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

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

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,  


View raw message