geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Summary? was: Session API....
Date Tue, 14 Mar 2006 08:38:00 GMT
Hiram Chirino wrote:

>>The Invocation type, that I am describing, is not bound to a specific
>>protocol (note that I mention both web and tiers above) - but an
>>abstraction over calls/rpcs/etc.. carried via a number of possible
>>transports : Http, OpenEJB, IIOP, various WS transports...
>Sounds interesting but a bit abstract.  Got a link to something that
>shows me what this generic invocation thing looks like?
Abstract is good - I thought that this was exactly what we were trying 
to achieve...

How about :

interface Invocation {

  Key getSessionKey();
  void setSessionKey(Key key);
  void setSessionTimeToLive(long ttl);

  // ... other manipulations that SessionManager may need to make in 
protocol independant way

  void relocate(Object opaque); // opaque arg holds protocol specific 
end-point, obtained from Session Manager at other end


>>>so it's main goal is to avoid defining a model for a Invocation.
>>If the Invocation were bound to a specific protocol, I would agree - but
>>it isn't.
>>>I do believe that it's goal  that It exposes enough information such
>>>as where the session is located, so the protocol specific Session APIs
>>>can be built on top of it.
>>So, we are beginning to reach a consensus here - the Session API is not
>>an API for Session Management, but an API for a State Manager that a
>>Session Manager might use. This is the conclusion that Greg and I came
>>to in our discussions.
>>Unfortunately, I think that this leaves half the problem in the client
>>container's domain. Jetty, Tomcat, OpenEJB, Axis etc already exist in
>>non-clustered form. What is needed is a Session Management API through
>>which clustered Session Managers can be plugged into these containers,
>>and others, and transparently and completely take over responsibility
>>for all clustering behaviour. What a State Management API provides is
>>not enough. The Container is left with the problem of talking to the
>Yes, I don't think it's the full picture.  But I do think the
>implementing clustered state management is one of the trickier parts
>to get implemented correctly.

>  The main performance characteristics of
>the clustered solution will sit squarely on the implementation of the
>clustered state manager.
I think that the ability to relocate Invocations as well as Sessions 
will have a major impact here. Whilst the API talks about this option, 
it makes no effort to encompass it.

>  Creating a clean interface into this level
>of functionality should allow for us to start with simple solution and
>evolve to more efficient implementations as time progresses.
But by positioning the interface at this level I think you are making 
things more complicated for client-container integrators, who will have 
to write clustering code, and people with existing solutions (me!), who 
may have to break their implementation up along artificial lines in 
order to adopt the API.

>>implementation behind this API about issues such as Location. This chunk
>>of Location-aware code may either be rewritten for each container, or
>>somehow shared between them. If you are sensible and go for the second
>>option, you find that half of your API (the piece concerning Location)
>>is not being used by the client Containers, but only by your piece of
>>shared code - i.e. it is drifting back from the API and into an area
>>where it does not actually need to be exposed at all....and that your
>>shared code needs to either be packaged with every client-container or
>>subsumed into your Session Manager - the latter being the most sensible
>Suppose we do come up with 1 uber session manager that can handle all
>kinds of container, I still think it's a good idea if he used the
>state manager via a clean set of interfaces for the reasons outlined
>above.  The upside is that if we can't find the perfect interface for
>an uber session manager that works with invocations, we can now have
>session managers that can be tailored for each container but still
>share the same state management layer.
Greg and I had already come to this conclusion as well. WADI is going 
for the UberSessionManager model. We already practically there, so 
having to go back and break the thing in half is an unwelcome distraction.

>>>    Illustrations :
>>>    1). I don't think that the Location of a Session if of any relevance
>>>    to the Consumer. Jetty/TC/ OpenEJB are simply interested in looking up
>>>    a Session and using it. A number of classes in
>Sometimes.. what about if they want to do a redirect?  Why would they
>need to always look up a session and cause a state transfer at all?
Then they call Invocation.relocate() (see above) and let the Invocation 
implementer (most likely the client-container writer ho has 
domain-specific expertise) worry about doing it in the most correct and 
efficient manner.

>>>    org.apache.geronimo.session talk in terms of Location. I see Location
>>>    as an implementation detail. WADI will have trouble mapping to some of
>>>    the assumptions that appear to be made in this part of the
>>>    API. e.g. Locator.getSessionLocation() is not an efficient thing to do
>>>    in WADI. It involves a round-trip to the owner of this section of the
>>>    Location Map. When WADI wants to move a Session it sends a message to
>>>    this node, which sends a message to the owner of the Session, which
>>>    sends a message containing the Session to the node that made the
>>>    request - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops)
>>>WADI could start caching that kind of location information and then it
>>>would not need RPC to get the data.  Seems like knowing the location
>>>of a session would be crucial in making a desicion to redirect, proxy,
>>>or move the session.
>>WADI does not need to RPC to get the data. This problem only arises for
>>WADI in trying to implement the proposed API.
>>WADI is designed as a Partitioned space, rather than a Shared cache,
>>with associated consistency and invalidation issues, specifically to
>>overcome the problems in scaling introduced by these issues. Introducing
>>a cache-based solution here would just introduce all the problems that
>>WADI is designed to resolve.
>Yes, but I still believe that the underling implementation can
>optimize out many of these issues.
>Another possible way to work around this is, If WADI assumes that the
>session manager never redirects, then it could implement it self so
>that looking up a location cause the session to actually move.  In
>other words, skip the RPC and just move the session
That is exactly what it does in this case - hence my problem with an API 
that imposes a lookup mechanism - it looks like a lookup, not a 
migration. It just doesn't fit. Furthermore, for the reasons that I have 
given, I think it is unecessary to have an API here at all.

>Point being is these are just interfaces and they can be implemented
>many different ways.
and my point being that interfaces necessarily impose structure and 
division between components and that I have outlined what I think are 
serious issues for a Session Mnagement API.

If we accept that it is a State management API for Session Managers, 
then, as I have explained, I think you will be bitten by the fact that 
you are only dealing with half of the problem.



"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message