geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: Summary? was: Session API....
Date Tue, 14 Mar 2006 02:35:10 GMT
> 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?

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

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

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.

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

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

Point being is these are just interfaces and they can be implemented
many different ways.


View raw message