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.
agreed
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
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.
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.
--
Regards,
Hiram
likewise,
Jules
--
"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)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
