geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Summary? was: Session API....
Date Mon, 13 Mar 2006 15:05:46 GMT
On 3/9/06, Jules Gosnell <jules@coredevelopers.net> 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 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
decisionsdifferently.  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.

--
Regards,
Hiram Snell
Jonell
Gospel
Cornell
Ginelle
Edit...
Ignore all
Add to dictionary
PRC
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
PRC
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"

Mime
View raw message