geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Tue, 28 Feb 2006 11:03:05 GMT

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.

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)
  + Does session ID x exist for context y
  + get WEB session with ID x for context y
  + invalidate ALL sessions with ID x  
  + passivate ALL sessions (suspending node)
  + invalidate ALL sessions (shutting down)

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.


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


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.




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.


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.

So firstly we need SessionLocatoin.moveto(Server server),
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.

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.



Anyway,   very soon, I'd like to start on the jetty6 geronimo
modules.  So perhaps a way to turn these negative comments into
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.


cheers





 




























Mime
View raw message