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:56:22 GMT
Actually, the more I think about it, you are bringing up the need for  
another API for request routing.  This would be something that can  
make a decision about what to do with a request and could optionally  
work with out session API.  I'm thinking of something that captures  
the concept of a request and a decision.  Off the top of my head...

public interface Request {
     Object getHeader();
     String getSessionId();
     String getTarget();

public interface Router {
     public RouterPolicy route(Request request);

RouterPolicy is an enumeration containing local, move session, proxy,  

With a simple API like this we should be able to enable smart load  
balancing features contained in the clustering implementations out  
there today, while keeping the caller's job simple.


On Mar 1, 2006, at 11:32 AM, Dain Sundstrom wrote:

> 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:
> test/org/apache/geronimo/session/
>> 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.
> test/org/apache/geronimo/session/remote/
> 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

View raw message