geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
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,  
redirect.

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.

-dain

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


Mime
View raw message