On 3/9/06, Jules Gosnell <jules@coredevelopers.net> wrote:

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

I think this generic Session API is trying to avoid getting into protocol specifics so it's main goal is to avoid defining a model for a Invocation.  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.

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.

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.