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 Mon, 13 Mar 2006 23:23:57 GMT
Hi Hiram :-)

Hiram Chirino wrote:

> On 3/9/06, *Jules Gosnell* < 
> <>> wrote:
>     3)
>     I think that you are completely omitting one of the key players from
>     this API. The Invocation. The goal of successful Session management is
>     that Invocation and Session should meet somewhere in the cluster for
>     the successful rendering/processing of a page/ rpc/whatever. The
>     Invocation carries all the information that you may wish to a)
>     intercept and process elsewhere, b) pass onto the Session management
>     layer to aid in its decision making upon creation, retrieval and
>     invalidation of a Session. Depending on how responsibilities are split
>     between client container and Session manager, the session management
>     layer may actually want to modify the return values in this
>     Invocation - adding removing session cookies/attributes, changing ttls
>     upon this attribute, changing the value of this attribute or altering
>     other information within the Invocation that is used to integrate it
>     better with the Client at the other end of the wire. All these
>     interactions should be opaque to the client-container
>     (Jetty/TC/ OpenEJB/...) and depend entirely on the implementation of
>     the Client (or e.g. Http loadbalancer) and the session management
>     layer.
> I think this generic Session API is trying to avoid getting into 
> protocol specifics

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

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

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

The point that I am trying to make is that this part of the API is not 
one that needs to be exposed to a client container anyway.

>     to find the location and one (another 2 hops) to retrieve it.
>     There is
>     actually a lot more detail involved here (another two hops are
>     involved in locking/unlocking etc) in which this API would create
>     further issue. Why bother to describe all implementations when the
>     Session consumer has no requirement ?
>     2). I'll call on the KISS principle here. I think that by exposing the
>     issues of colocation in the API, you are moving complexity from the
>     implementation into the API. I think the priority should be to keep
>     the API simple. At the creation of a Session the client container
> I think that every protocol is going to make session management 
> decisions differently.  Not every protocol can do a redirect for 
> example.  They should be the ones in charge of deciding how to get the 
> invocation and the session to meet. 

So you have hit the nail right on the head :-). This is why you need an 
abstraction like Invocation. The Container passes an Invocation to the 
SessionManager upon its entry and exiting the container. Each Invocation 
subtype knows how to support a small number of operations i.e. relocate 
itself to another node. This may be achieved through an Http Redirect or 
HttpProxy for web, and one or more equivalents for other protocols... 
The piece of Location-aware code described above (Greg's 'Policy') can 
make the decision as to whether to ask the Invocation to reroute itself 
to the node holding the Session, to summon the Session to the node on 
which the Invocation has arrived, or to migrate both of them to be 
combined elsewhere. The 'Policy' needs to know nothing specific about 
the protocol encapsulated in the Invocation and the Container needs to 
know nothing about how the Policy is written. The SessionManager is 
assembled with pluggable policy outside the client-Container as e.g. a 
GBean. The client-Container acquires a reference to the SessionManager 
at startup and delegates all Session-related decisions to it 
thenceforth. The client-Container need never even be aware of the 
existence or type of the Policy as it is completely enapsulated by the 

> -- 
> Regards,
> Hiram
> Snell
> Jonell
> Gospel
> Cornell
> Ginelle
> Edit...
> Ignore all
> Add to dictionary
> PC
> RC
> RP
> Ric
> Edit...
> Ignore all
> Add to dictionary
> tls
> tels
> ttys
> Tl's
> til's
> Edit...
> Ignore all
> Add to dictionary
> Punjab
> Punjabi
> Edit...
> Ignore all
> Add to dictionary
> load balancer
> outbalance
> lovableness
> lordliness
> likableness
> Edit...
> Ignore all
> Add to dictionary
> generic
> Gerick
> Garrick
> Gerek
> Gerik
> Edit...
> Revert to "gereric"
> AP Is
> AP-Is
> Apia
> Apish
> AIs
> Edit...
> Ignore all
> Add to dictionary
> Punjab
> Punjabi
> Edit...
> Ignore all
> Add to dictionary
> (No suggestions)
> Edit...
> Ignore all
> Add to dictionary
> (No suggestions)
> Edit...
> Ignore all
> Add to dictionary
> PC
> RC
> RP
> Ric
> Edit...
> Ignore all
> Add to dictionary
> decision
> deicing
> desiring
> design
> discoing
> Edit...
> Ignore all
> Add to dictionary
> co location
> co-location
> collocation
> coloration
> collocations
> Edit...
> Ignore all
> Add to dictionary
> management
> managements
> management's
> Edit...
> Revert to "managment"
> decisions
> sessions
> cessions
> session's
> delusions
> Edit...
> Revert to "dessions"

In conclusion, the mismatch between WADI's approach and that of the 
proposed API is that WADI is a SessionManager that takes responsibility 
for all clustering related issues associated with Session management, 
shields the client-container from even having to be aware that it is 
running in a clustered environment and aims to allow the same set of 
pluggable policies to be reused no matter what the underlying transport, 
invocation or session implementation looks like, whereas the proposed 
API seems only concerned with state management and seems happy to expose 
clustering related issues to its client-containers where they may be 
resolved in a number of different and inconsistant ways. I really 
believe that state management is only half the problem and that unless 
we take a more wholistic approach you are going to end up with a number 
of confused container integrators who all have a slightly different idea 
of how their container should be made cluster-aware.


"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