You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/03/01 20:32:08 UTC
Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Wow, this is a lot to digest. I'll attempt, but we may want to deal
with these one by one...
On Feb 28, 2006, at 3:03 AM, Greg Wilkins wrote:
>
> Responding to this a bit late....
>
>
> I like the concept of a Session API that can hide
> all the variations of session implementations from the web container.
> Instead of having different session managers for the different
> clustering mechanisms, I'd like to have one session manager
> written to this API that receives a Locator implementation and
> everything else is hidden from it.
>
> This API looks like a good start, but I think it is missing lots
> that I'll need to write a jetty session manager that is based on
> it:
>
>
> ID Management
> =============
> Firstly, the API represents a flat session ID space and
> I'm not sure that is sufficient. With cross context
> dispatch you may have several different web sessions that
> share the same ID. Also, EJB sessions may share that
> ID and may be at different locations to the web session.
The idea was to build the simplest API that could preform. We tried
to leave complex session constructs out of the API. James and I did
talk about some of this stuff and thought we could simply build a
complex string to lookup the session data in the flat map.
> So I think the API needs some more capabilities for
> session ID management. Specifically the following questions
> needs to be asked and answered:
>
> + Does session ID x exist in the whole server/cluster)
You always know every session that exists in the cluster:
locator.getSessionLocation(x)
> + Does session ID x exist for context y
In this case, I would say you lookup the session "x" and then see if
it has an entry for context "y"
> + get WEB session with ID x for context y
No idea what that means
> + invalidate ALL sessions with ID x
SessionLocation.destroy()
> + passivate ALL sessions (suspending node)
That would happen under the covers of the session API (i.e.,
implementation specific)
> + invalidate ALL sessions (shutting down)
Implementation specific
> Now the above could be modelled with deep structure for the
> state associated with an ID, but not if all state for an ID
> has to be in one location.
Having all of the state for a single session located on a single
machine is a design assumption. We felt that if you wanted to let
the data be divided across several machines it was not a single
session session.
> Session Management
> ==================
> There is nothing in the API to help with session management.
> Specifically:
>
> + last access time
> + access session (without actually modify state)
> + invalidate session
> + session timeouts
> + session events (eg session invalidation, passivation etc.)
Other than last access time, I would classify this as implementation
specific. The goal was to create a very very simply API that
OpenEJB, ServiceMix, Lingo, Tuscany and web containers could use
without haveing to know the internal details of the implementation.
Does you code specifically need this or it is a nice to have? If it
is the former, can you be a lot more specic on what the terms above
mean (I'm not a web expert) :)
> Locking
> =======
> I'm also not sure about the semantics of release(). If I'm
> writing a session manager, I'm not sure if I should be making
> the decision of when to release - that is very much implementation
> dependent. Some will replicate/sync on a setState, others will
> do it at the end of every request, other will do it every n seconds
> others will do it when the session is idle (has no requests).
>
> Instead of commanding "release", perhaps the API should allow
> the concept of a thread entering and existing a session scope:
>
> runInSessionScope(Runnable doSomething
>
> or
>
> enterSessionScope()
> leaveSessionScope()
>
> individual implementations can decide what locking they
> implement behind the scenes.
That is exactly how the API works. When you start using a session
you need to acquire it using the Locator and when you are done using
it, you release it. This is reference counting, and when the count
reaches zero we are in a stable state and can replicate. Here is a
test case that shows normal usage:
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
test/org/apache/geronimo/session/SessionTest.java
> Policy
> ======
>
> The SessionLocation interface has the start of a policy
> API for managing session location. Cool, but I don't
> want the web SessionManager to have to implement policy.
> I don't want to have to call moveLocally() - I want something
> else to have called that before the request comes near
> the web containers session manager.
>
> So I think the API needs to have the concept of a Policy
> implementation that can be invoked before and after a
> session is accessed.
I'm not sure exactly what you are looking for, but the following test
case shows the usage of move, redirect or proxy policies.
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
test/org/apache/geronimo/session/remote/RemoteSessionTest.java
We could add an API for making this decision, but I think the
decision policy is very specific to the client. For example, in EJB
you normally have a smart client, so the default policy is should be
clien side redirect.
> Meta Data
> =========
>
> To implement a policy, we are going to need to implement
> some meta data channelling. For example, if we are running
> in the scenario where requests can be proxied to where a
> session lives - we might want to have a policy that if
> a session sees lots of requests being proxied from a
> specific node (load balancer changed?) then that session
> might want to move itself to that node.
Assuming we do add an interface to make the decision, I would hope
that all of these details would be implementation specific (i.e.,
under the covers of a very simple interface).
> So firstly we need SessionLocatoin.moveto(Server server),
I'm confused. Why would we need that?
> but more importantly, when we are redirecting or proxying
> requests, it would be good to be able to attach impl
> specific meta data to those requests. So the HTTP tier
> needs to be able to ask a SessionLocation for an opaque
> blob of meta data associated with a request and to be
> able to set that meta data when it recieves it.
Huh? Redirect would be dependent on the web container so this would
be a detail for the web container to deal with. The session apis,
only says, "the session data is on server x". How the web container
gets the request to server x is it's problem.
> I guess the nodes could communicate that meta data via
> out-of-band paths, but then you are in a world of synchronization
> pain - specially if the cluster grows, shrinks or changes.
I'm really confused now. I don't know why you would need any kind of
out-of-band meta data. The session apis are designed around the
concept of movable locks. In a moveable lock system, you only need
to know where the lock is located. If it is on your local machine
you just grab the lock. If it is remote, you can either move the
lock to the lock request, or move the lock request to the lock.
There should be no need for extra metadata, and the system should
scale very well.
> Anyway, very soon, I'd like to start on the jetty6 geronimo
> modules. So perhaps a way to turn these negative comments into
I didn't take these negatively at all. You are stating to look at
these from a user's perspective and there will always be confusion,
missing features and problems in new APIs.
> positive suggestions is if I try to use the jetty6 module to
> implement a session manager based on this API and then make changes
> to make it work.
I would prefer that we discuss the API changes first. There are many
uses for this API and I want to keep them simple and avoid making
them to servlet centric. I think if we carefully work out the APIs
we can have something that works well for all of the users (i.e.,
OpenEJB, ServiceMix, Lingo, Tuscany and web containers) and the
implementers (i.e., WADI, ehCache, java.util.HashMap, TangoSol,
ObjectGrid).
-dain
Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by James Strachan <ja...@gmail.com>.
On 1 Mar 2006, at 19:56, Dain Sundstrom wrote:
> Actually, the more I think about it, you are bringing up the need
> for another API for request routing. This would be something that
> can make a decision about what to do with a request and could
> optionally work with out session API. I'm thinking of something
> that captures the concept of a request and a decision. Off the top
> of my head...
>
> public interface Request {
> Object getHeader();
> String getSessionId();
> String getTarget();
> }
>
> public interface Router {
> public RouterPolicy route(Request request);
> }
>
> RouterPolicy is an enumeration containing local, move session,
> proxy, redirect.
>
> With a simple API like this we should be able to enable smart load
> balancing features contained in the clustering implementations out
> there today, while keeping the caller's job simple.
Agreed - I think there's a requirement for the container (web/JBI/EJB/
SCA) to not worry at all about this stuff and just delegate to some
policy which decides whether to proxy, move, redirect. I hacked up a
little strawman
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
java/org/apache/geronimo/session/remote/util/
DefaultRemoteSessionStrategy.java
but as you suggest, I think being able to pass in more metadata to
the policy would be a good idea
James
-------
http://radio.weblogs.com/0112098/
Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
Actually, the more I think about it, you are bringing up the need for
another API for request routing. This would be something that can
make a decision about what to do with a request and could optionally
work with out session API. I'm thinking of something that captures
the concept of a request and a decision. Off the top of my head...
public interface Request {
Object getHeader();
String getSessionId();
String getTarget();
}
public interface Router {
public RouterPolicy route(Request request);
}
RouterPolicy is an enumeration containing local, move session, proxy,
redirect.
With a simple API like this we should be able to enable smart load
balancing features contained in the clustering implementations out
there today, while keeping the caller's job simple.
-dain
On Mar 1, 2006, at 11:32 AM, Dain Sundstrom wrote:
> Wow, this is a lot to digest. I'll attempt, but we may want to
> deal with these one by one...
>
> On Feb 28, 2006, at 3:03 AM, Greg Wilkins wrote:
>
>>
>> Responding to this a bit late....
>>
>>
>> I like the concept of a Session API that can hide
>> all the variations of session implementations from the web container.
>> Instead of having different session managers for the different
>> clustering mechanisms, I'd like to have one session manager
>> written to this API that receives a Locator implementation and
>> everything else is hidden from it.
>>
>> This API looks like a good start, but I think it is missing lots
>> that I'll need to write a jetty session manager that is based on
>> it:
>>
>>
>> ID Management
>> =============
>> Firstly, the API represents a flat session ID space and
>> I'm not sure that is sufficient. With cross context
>> dispatch you may have several different web sessions that
>> share the same ID. Also, EJB sessions may share that
>> ID and may be at different locations to the web session.
>
> The idea was to build the simplest API that could preform. We
> tried to leave complex session constructs out of the API. James
> and I did talk about some of this stuff and thought we could simply
> build a complex string to lookup the session data in the flat map.
>
>> So I think the API needs some more capabilities for
>> session ID management. Specifically the following questions
>> needs to be asked and answered:
>>
>> + Does session ID x exist in the whole server/cluster)
>
> You always know every session that exists in the cluster:
>
> locator.getSessionLocation(x)
>
>> + Does session ID x exist for context y
>
> In this case, I would say you lookup the session "x" and then see
> if it has an entry for context "y"
>
>> + get WEB session with ID x for context y
>
> No idea what that means
>
>> + invalidate ALL sessions with ID x
>
> SessionLocation.destroy()
>
>> + passivate ALL sessions (suspending node)
>
> That would happen under the covers of the session API (i.e.,
> implementation specific)
>
>> + invalidate ALL sessions (shutting down)
>
> Implementation specific
>
>> Now the above could be modelled with deep structure for the
>> state associated with an ID, but not if all state for an ID
>> has to be in one location.
>
> Having all of the state for a single session located on a single
> machine is a design assumption. We felt that if you wanted to let
> the data be divided across several machines it was not a single
> session session.
>
>> Session Management
>> ==================
>> There is nothing in the API to help with session management.
>> Specifically:
>>
>> + last access time
>> + access session (without actually modify state)
>> + invalidate session
>> + session timeouts
>> + session events (eg session invalidation, passivation etc.)
>
> Other than last access time, I would classify this as
> implementation specific. The goal was to create a very very simply
> API that OpenEJB, ServiceMix, Lingo, Tuscany and web containers
> could use without haveing to know the internal details of the
> implementation. Does you code specifically need this or it is a
> nice to have? If it is the former, can you be a lot more specic on
> what the terms above mean (I'm not a web expert) :)
>
>> Locking
>> =======
>> I'm also not sure about the semantics of release(). If I'm
>> writing a session manager, I'm not sure if I should be making
>> the decision of when to release - that is very much implementation
>> dependent. Some will replicate/sync on a setState, others will
>> do it at the end of every request, other will do it every n seconds
>> others will do it when the session is idle (has no requests).
>>
>> Instead of commanding "release", perhaps the API should allow
>> the concept of a thread entering and existing a session scope:
>>
>> runInSessionScope(Runnable doSomething
>>
>> or
>>
>> enterSessionScope()
>> leaveSessionScope()
>>
>> individual implementations can decide what locking they
>> implement behind the scenes.
>
> That is exactly how the API works. When you start using a session
> you need to acquire it using the Locator and when you are done
> using it, you release it. This is reference counting, and when the
> count reaches zero we are in a stable state and can replicate.
> Here is a test case that shows normal usage:
>
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
> test/org/apache/geronimo/session/SessionTest.java
>
>> Policy
>> ======
>>
>> The SessionLocation interface has the start of a policy
>> API for managing session location. Cool, but I don't
>> want the web SessionManager to have to implement policy.
>> I don't want to have to call moveLocally() - I want something
>> else to have called that before the request comes near
>> the web containers session manager.
>>
>> So I think the API needs to have the concept of a Policy
>> implementation that can be invoked before and after a
>> session is accessed.
>
> I'm not sure exactly what you are looking for, but the following
> test case shows the usage of move, redirect or proxy policies.
>
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
> test/org/apache/geronimo/session/remote/RemoteSessionTest.java
>
> We could add an API for making this decision, but I think the
> decision policy is very specific to the client. For example, in
> EJB you normally have a smart client, so the default policy is
> should be clien side redirect.
>
>> Meta Data
>> =========
>>
>> To implement a policy, we are going to need to implement
>> some meta data channelling. For example, if we are running
>> in the scenario where requests can be proxied to where a
>> session lives - we might want to have a policy that if
>> a session sees lots of requests being proxied from a
>> specific node (load balancer changed?) then that session
>> might want to move itself to that node.
>
> Assuming we do add an interface to make the decision, I would hope
> that all of these details would be implementation specific (i.e.,
> under the covers of a very simple interface).
>
>> So firstly we need SessionLocatoin.moveto(Server server),
>
> I'm confused. Why would we need that?
>
>> but more importantly, when we are redirecting or proxying
>> requests, it would be good to be able to attach impl
>> specific meta data to those requests. So the HTTP tier
>> needs to be able to ask a SessionLocation for an opaque
>> blob of meta data associated with a request and to be
>> able to set that meta data when it recieves it.
>
> Huh? Redirect would be dependent on the web container so this
> would be a detail for the web container to deal with. The session
> apis, only says, "the session data is on server x". How the web
> container gets the request to server x is it's problem.
>
>> I guess the nodes could communicate that meta data via
>> out-of-band paths, but then you are in a world of synchronization
>> pain - specially if the cluster grows, shrinks or changes.
>
> I'm really confused now. I don't know why you would need any kind
> of out-of-band meta data. The session apis are designed around the
> concept of movable locks. In a moveable lock system, you only need
> to know where the lock is located. If it is on your local machine
> you just grab the lock. If it is remote, you can either move the
> lock to the lock request, or move the lock request to the lock.
> There should be no need for extra metadata, and the system should
> scale very well.
>
>> Anyway, very soon, I'd like to start on the jetty6 geronimo
>> modules. So perhaps a way to turn these negative comments into
>
> I didn't take these negatively at all. You are stating to look at
> these from a user's perspective and there will always be confusion,
> missing features and problems in new APIs.
>
>> positive suggestions is if I try to use the jetty6 module to
>> implement a session manager based on this API and then make changes
>> to make it work.
>
> I would prefer that we discuss the API changes first. There are
> many uses for this API and I want to keep them simple and avoid
> making them to servlet centric. I think if we carefully work out
> the APIs we can have something that works well for all of the users
> (i.e., OpenEJB, ServiceMix, Lingo, Tuscany and web containers) and
> the implementers (i.e., WADI, ehCache, java.util.HashMap, TangoSol,
> ObjectGrid).
>
> -dain
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 6, 2006, at 1:01 AM, Greg Wilkins wrote:
> James Strachan wrote:
>
>>> I think a moveTo will also be useful for implementing shutdown
>>> policies, where you want to gently take a node out of a cluster.
>>> The policy should be able to be written independently of impl.
>>
>>
>> I don't think the non-web world needs it that much as there typically
>> isn't a crazy load balancer in the way smoking crack and doing wacky
>> stuff.
>>
>> Both moveHere and moveThere could very well be valid decisions that
>> either the container or some Policy class can choose to do - I'd just
>> like to explore the use case a little further to check there is a
>> need.
>> BTW I don't think its a huge biggie as moveHere and moveThere are
>> kinda
>> similar.
>>
>> Normally when a request hits a node the session is here or its
>> overThere. So the use case you are suggesting is, the session is
>> locally here but the node decides to move the session overThere -
>> then
>> it must redirect/proxy the current request to overThere right? It
>> probably wants to do that to give the load balancer a clue of
>> where the
>> session really is; in which case the redirected/proxied request will
>> have the session locally - then it can decide if its gonna move the
>> session or not. The complication of the node who owns a session
>> deciding where to send it is that she doesn't know what the other
>> nodes
>> are doing per se; which is why its easier to do the moves from the
>> other way around. i.e. the node thats getting hit a lot decides
>> to grab
>> the session. A node that rarely gets hit doesn't know which node is
>> really getting hammered per se - so why not proxy/ redirect and
>> let that
>> guy decide?
>>
>> Like I say - no biggie either way - just wanting to clarify if we
>> really need this.
>
>
> In the context of a request being receive, the choice is almost
> always going to be between: 1) proxy request and 2) move session
> Local.
>
> So moveTo is not needed in that case.
>
> moveTo is needed in the cases outside of the context of a request:
>
> If the policy algorithm wants to shutdown a node, it can move
> requests away from that node.
>
> If the policy algorithm does not evaluate how well balanced it
> is on every request, but every few seconds - then it may detect
> misplaced sessions and need to move them. Note that an
> individual
> node receiving an individual request is unlikely to have sufficient
> information to make the correct choice between proxy and moveLocal -
> it will be a guess and some meta evaluation will be needed to
> balance
> the cluster.
>
> Ditto for when you have a programable load balancer - some meta
> policy might need to balance the cluster and move sessions around.
>
>
> At the end of the day, I think if we drop moveLocal and just have
> moveTo
> (which covers the moveLocal case) - then we cover all bases and have
> very little extra complexity in the API.
I think this should be implemented under the covers of the Session
API. This third party controller, will have to be specific to the
implementation anyway, since it will need custom metadata from each
node to make decisions, and therefore it can communicate with the
node using a custom interface that includes a moveTo method.
I say if over time we discover that everyone implementing the session
API are adding this feature, and there is a desire for these groups
to interop, we can discuss adding such a feature then.
-dain
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
James Strachan wrote:
>> I think a moveTo will also be useful for implementing shutdown
>> policies, where you want to gently take a node out of a cluster.
>> The policy should be able to be written independently of impl.
>
>
> I don't think the non-web world needs it that much as there typically
> isn't a crazy load balancer in the way smoking crack and doing wacky
> stuff.
>
> Both moveHere and moveThere could very well be valid decisions that
> either the container or some Policy class can choose to do - I'd just
> like to explore the use case a little further to check there is a need.
> BTW I don't think its a huge biggie as moveHere and moveThere are kinda
> similar.
>
> Normally when a request hits a node the session is here or its
> overThere. So the use case you are suggesting is, the session is
> locally here but the node decides to move the session overThere - then
> it must redirect/proxy the current request to overThere right? It
> probably wants to do that to give the load balancer a clue of where the
> session really is; in which case the redirected/proxied request will
> have the session locally - then it can decide if its gonna move the
> session or not. The complication of the node who owns a session
> deciding where to send it is that she doesn't know what the other nodes
> are doing per se; which is why its easier to do the moves from the
> other way around. i.e. the node thats getting hit a lot decides to grab
> the session. A node that rarely gets hit doesn't know which node is
> really getting hammered per se - so why not proxy/ redirect and let that
> guy decide?
>
> Like I say - no biggie either way - just wanting to clarify if we
> really need this.
In the context of a request being receive, the choice is almost
always going to be between: 1) proxy request and 2) move session Local.
So moveTo is not needed in that case.
moveTo is needed in the cases outside of the context of a request:
If the policy algorithm wants to shutdown a node, it can move
requests away from that node.
If the policy algorithm does not evaluate how well balanced it
is on every request, but every few seconds - then it may detect
misplaced sessions and need to move them. Note that an individual
node receiving an individual request is unlikely to have sufficient
information to make the correct choice between proxy and moveLocal -
it will be a guess and some meta evaluation will be needed to balance
the cluster.
Ditto for when you have a programable load balancer - some meta
policy might need to balance the cluster and move sessions around.
At the end of the day, I think if we drop moveLocal and just have moveTo
(which covers the moveLocal case) - then we cover all bases and have
very little extra complexity in the API.
cheers
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
James Strachan wrote:
>> I think a moveTo will also be useful for implementing shutdown
>> policies, where you want to gently take a node out of a cluster.
>> The policy should be able to be written independently of impl.
>
>
> I don't think the non-web world needs it that much as there typically
> isn't a crazy load balancer in the way smoking crack and doing wacky
> stuff.
>
> Both moveHere and moveThere could very well be valid decisions that
> either the container or some Policy class can choose to do - I'd just
> like to explore the use case a little further to check there is a need.
> BTW I don't think its a huge biggie as moveHere and moveThere are kinda
> similar.
>
> Normally when a request hits a node the session is here or its
> overThere. So the use case you are suggesting is, the session is
> locally here but the node decides to move the session overThere - then
> it must redirect/proxy the current request to overThere right? It
> probably wants to do that to give the load balancer a clue of where the
> session really is; in which case the redirected/proxied request will
> have the session locally - then it can decide if its gonna move the
> session or not. The complication of the node who owns a session
> deciding where to send it is that she doesn't know what the other nodes
> are doing per se; which is why its easier to do the moves from the
> other way around. i.e. the node thats getting hit a lot decides to grab
> the session. A node that rarely gets hit doesn't know which node is
> really getting hammered per se - so why not proxy/ redirect and let that
> guy decide?
>
> Like I say - no biggie either way - just wanting to clarify if we
> really need this.
In the context of a request being receive, the choice is almost
always going to be between: 1) proxy request and 2) move session Local.
So moveTo is not needed in that case.
moveTo is needed in the cases outside of the context of a request:
If the policy algorithm wants to shutdown a node, it can move
requests away from that node.
If the policy algorithm does not evaluate how well balanced it
is on every request, but every few seconds - then it may detect
misplaced sessions and need to move them. Note that an individual
node receiving an individual request is unlikely to have sufficient
information to make the correct choice between proxy and moveLocal -
it will be a guess and some meta evaluation will be needed to balance
the cluster.
Ditto for when you have a programable load balancer - some meta
policy might need to balance the cluster and move sessions around.
At the end of the day, I think if we drop moveLocal and just have moveTo
(which covers the moveLocal case) - then we cover all bases and have
very little extra complexity in the API.
cheers
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by James Strachan <ja...@gmail.com>.
On 2 Mar 2006, at 07:55, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>
>>> Policy
>>> ======
>
>>> So firstly we need SessionLocatoin.moveto(Server server),
>>
>> I'm confused. Why would we need that?
>
> There is an API to pull a session to a local node, but there
> is no API to push a session to a specific node.
>
> The use-case for the later if you have a load balancer that is
> a bit erratic and may scatter requests around a bit (think mod_jk
> after it has lost a node).
>
> If you have a policy where every node that receives a request
> pulls the session to it, then the session will expensively bounce
> around the cluster.
Note you can proxy or redirect - you don't have to move it locally
> Instead you can have a policy where you proxy (or redirect) the
> request to the node where the session is. This work fine, but at
> the cost of a proxy. If all or most of the requests are being
> sent to a specific node, then the session itself should be
> able to decide to migrate to that node: "I've been receiving
> most of my requests via node 7, so I think I'll move there".
>
> Thus we need a moveTo.
>
> I think a moveTo will also be useful for implementing shutdown
> policies, where you want to gently take a node out of a cluster.
> The policy should be able to be written independently of impl.
I don't think the non-web world needs it that much as there typically
isn't a crazy load balancer in the way smoking crack and doing wacky
stuff.
Both moveHere and moveThere could very well be valid decisions that
either the container or some Policy class can choose to do - I'd just
like to explore the use case a little further to check there is a
need. BTW I don't think its a huge biggie as moveHere and moveThere
are kinda similar.
Normally when a request hits a node the session is here or its
overThere. So the use case you are suggesting is, the session is
locally here but the node decides to move the session overThere -
then it must redirect/proxy the current request to overThere right?
It probably wants to do that to give the load balancer a clue of
where the session really is; in which case the redirected/proxied
request will have the session locally - then it can decide if its
gonna move the session or not. The complication of the node who owns
a session deciding where to send it is that she doesn't know what the
other nodes are doing per se; which is why its easier to do the moves
from the other way around. i.e. the node thats getting hit a lot
decides to grab the session. A node that rarely gets hit doesn't know
which node is really getting hammered per se - so why not proxy/
redirect and let that guy decide?
Like I say - no biggie either way - just wanting to clarify if we
really need this.
>
>
>
>
>>> but more importantly, when we are redirecting or proxying
>>> requests, it would be good to be able to attach impl
>>> specific meta data to those requests. So the HTTP tier
>>> needs to be able to ask a SessionLocation for an opaque
>>> blob of meta data associated with a request and to be
>>> able to set that meta data when it recieves it.
>>
>>
>> Huh? Redirect would be dependent on the web container so this
>> would be
>> a detail for the web container to deal with. The session apis, only
>> says, "the session data is on server x". How the web container gets
>> the request to server x is it's problem.
>
> I totally agree that it is the web-servers problem to
> move a request from one node to the other node.
>
> But I think there will be a need for some opaque impl
> specific data to be sent with that request - so the
> impl can coordinate it's actions.
>
> At the very least, it would be good for a request arriving
> on node x to be able to carry the opaque message: "I came from
> node z". It is easy for the web container to add such messages,
> but there is no way they can be passed to the policy impl.
Yeah; when proxying/redirecting we need some way to pass in some
information so that the Policy/container can make better session-
movement decisions. Though I think thats a nice to have - a real
simple algorithm (like the one in SVN) could well work for lots of folks
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
java/org/apache/geronimo/session/remote/util/
DefaultRemoteSessionStrategy.java
James
-------
http://radio.weblogs.com/0112098/
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly straight
forward. Let me see if I can give an idea of how the API shouldn't need
to worry, its a little lengthy, but it shows that the Session and the
SessionManager need to know zero about clustering or session locations.
(this is only one solution, and other solutions should demonstrate the
same point, SessionAPI need to know nothing about clustering or session
locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry combinations
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one,
and do a publish to the entire cluster of the locations.
As you can see, all-to-all communications only happens when a Session is
(created|destroyed|failover). Other than that it is primary-to-backup
communication only, and this can be in terms of diffs or entire sessions
using the isDirty or getDiff. This is triggered either by an interceptor
at the end of each request or by a batch process for less network jitter
but less accuracy (but adequate) for fail over.
As you can see, access time is not relevant here, nor does the Session
API even know about clustering.
In tomcat we have separated out group communication into a separate
module, we are implementing the LazyReplicatedHashMap right now just for
this purpose.
positive thoughts, criticism and bashing are all welcome :)
Filip
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Filip Hanik - Dev Lists wrote:
> gentlemen, not a committer here, but wanted to share some thoughts.
>
> in my opinion, the Session API should not have to know about clustering
> or session replication, nor should it need to worry about location.
> the clustering API should take care of all of that.
Filip,
I think the API should be thought of in two parts:
a session API
a session policy API.
The bits about location etc. are all in the session policy API.
The mechanism you describe below for replication, is just one way
to handle session state in a cluster.
You may have distributed state without replication
You may have a central stor of state (eg database) with it's
own fault tolerance and clustering capabilites.
Also, good session management needs to take place proactively -
not just when the session API is being called. Nodes need to be
shutdown, load might need to be rebalanced. So having an
API that does know about session location and has the ability
to move them will allow the development of plugable and
configurable policies that manage the way state moves
around a cluster.
So I hope that the implementation that you describe below could
become one of the implementations of the G session API. Then
when a geronimo cluster wishes to shutdown a node, it can use this
API to tell your LazyReplicatedHashMap to move sessions off a node
(or to find a different backup for sessions on other nodes).
This could be done without writing LazyReplicatedHashMap specific
code.
cheers
> the solution that we plan to implement for Tomcat is fairly straight
> forward. Let me see if I can give an idea of how the API shouldn't need
> to worry, its a little lengthy, but it shows that the Session and the
> SessionManager need to know zero about clustering or session locations.
> (this is only one solution, and other solutions should demonstrate the
> same point, SessionAPI need to know nothing about clustering or session
> locations)
>
> 1. Requirements to be implemented by the Session.java API
> bool isDirty - (has the session changed in this request)
> bool isDiffable - is the session able provide a diff
> byte[] getSessionData() - returns the whole session
> byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
> changes from another node
>
> 2. Requirements to be implemented by the SessionManager.java API
> void setSessionMap(HashMap map) - makes the map implementation pluggable
>
> 3. And the key to this, is that we will have an implementation of a
> LazyReplicatedHashMap
> The key object in this map is the session Id.
> The map entry object is an object that looks like this
> ReplicatedEntry {
> string id;//sessionid
> bool isPrimary; //does this node hold the data
> bool isBackup; //does this node hold backup data
> Session session; //not null values for primary and backup nodes
> Member primary; //information about the primary node
> Member backup; //information about the backup node
> }
>
> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>
> So all the nodes will have the a sessionId,ReplicatedEntry combinations
> in their session map. But only two nodes will have the actual data.
> This solution is for sticky LB only, but when failover happens, the LB
> can pick any node as each node knows where to get the data.
> The newly selected node, will keep the backup node or select a new one,
> and do a publish to the entire cluster of the locations.
>
> As you can see, all-to-all communications only happens when a Session is
> (created|destroyed|failover). Other than that it is primary-to-backup
> communication only, and this can be in terms of diffs or entire sessions
> using the isDirty or getDiff. This is triggered either by an interceptor
> at the end of each request or by a batch process for less network jitter
> but less accuracy (but adequate) for fail over.
>
> As you can see, access time is not relevant here, nor does the Session
> API even know about clustering.
>
> In tomcat we have separated out group communication into a separate
> module, we are implementing the LazyReplicatedHashMap right now just for
> this purpose.
>
> positive thoughts, criticism and bashing are all welcome :)
>
> Filip
>
>
>
>
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
btw, for very large clusters, you use the same mechanism, except,
instead of distributing the entire session map, the backup node info is
stored in a cookie.
and by doing this, you don't need to remember the backup location
throughout the cluster. you still broadcast cancellations of primary
node to account for false positive.
the only scenario that is not accounted for is when you have a wacky lb
that sends two parallel requests to two different servers. this would
require distributed locking, and that is a path that is too much
overhead to walk down.
Filip
Filip Hanik - Dev Lists wrote:
> Hi Dain,
> let me address the location, and show you how the location is
> completely transparent.
>
> The way the LazyReplicatedMap works is as follows:
> 1. Backup node fails -> primary node chooses a new backup node
> 2. Primary node fails -> since Tomcat doesn't know which node the user
> will come to their
> next http request, nothing is done.
> When the user makes a request, and the session manager says
> LazyMap.getSession(id) and that session is not yet on the server,
> the lazymap will request the session from the backup server, load it
> up, set this node as primary.
> that is why it is called lazy, cause it wont load the session until
> it is actually needed, and because it doesn't know what node will
> become primary, this is decided by the load balancer. remember, that
> each node knows where the session with Id=XXXX is located. they all
> carry the same map, but only two carry the data (primary secondary).
>
> on a false positive, the new primary node will cancel out the old one.
> so you can have as many false positives as you want, but the more you
> have the worse your performance will get :). that is why sticky lb is
> important, but false positive is handled the same way as a crash
> except that the old primary gets cancelled out.
>
> the rest is inlined
>>>
>>> 1. Requirements to be implemented by the Session.java API
>>> bool isDirty - (has the session changed in this request)
>>> bool isDiffable - is the session able provide a diff
>>> byte[] getSessionData() - returns the whole session
>>> byte[] getSessionDiff() - optional, see isDiffable, resets the
>>> diff data
>>> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
>>> changes from another node
>>
>> To throw you arguments back on you, why should my code be exposed to
>> this level of detail :) From my perspective, I get a session and it
>> is the Session API implementation's problem to figure out how to diff
>> it, back it up, and migrate it.
>>
> exactly. the methods above is what is required from the servlet
> container, not the webapp developer.
> so if you are a jetty developer, you would implement the above
> methods. This way, the jetty developer can optimize the serialization
> algorithm, and locking (during diff creation), and your session will
> never be out of date. in tomcat, we are making the getSessionDiff() a
> pluggable algorithm, but it is implemented in the container,
> otherwise, just serialization is too slow.
>
>>> 2. Requirements to be implemented by the SessionManager.java API
>>> void setSessionMap(HashMap map) - makes the map implementation
>>> pluggable
>>>
>>> 3. And the key to this, is that we will have an implementation of a
>>> LazyReplicatedHashMap
>>> The key object in this map is the session Id.
>>> The map entry object is an object that looks like this
>>> ReplicatedEntry {
>>> string id;//sessionid
>>> bool isPrimary; //does this node hold the data
>>> bool isBackup; //does this node hold backup data
>>> Session session; //not null values for primary and backup nodes
>>> Member primary; //information about the primary node
>>> Member backup; //information about the backup node
>>> }
>>>
>>> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>>
>> Why would anyone need to know this level of detail?
> you don't and you will not, I just giving you some architectural
> insight on how it works under the hood :)
>
>>
>>> So all the nodes will have the a sessionId,ReplicatedEntry
>>> combinations in their session map. But only two nodes will have the
>>> actual data.
>>> This solution is for sticky LB only, but when failover happens, the
>>> LB can pick any node as each node knows where to get the data.
>>> The newly selected node, will keep the backup node or select a new
>>> one, and do a publish to the entire cluster of the locations.
>>
>> I don't see anyway to deal with locking or the fact that servlet
>> sessions are multi threaded (overlaping requests). How do you know
>> when the session is not being used by anyone so you have a stable
>> state for replication.
> in tomcat we have an access counter, gets incremented when the request
> comes in, and decremented when the request leaves. if the counter is
> 0, lock the session and suck out the diff. or just lock it at the end
> of each request on a periodic basis, regardless of what the counter is.
>
>>
>>> As you can see, all-to-all communications only happens when a
>>> Session is (created|destroyed|failover). Other than that it is
>>> primary-to-backup communication only, and this can be in terms of
>>> diffs or entire sessions using the isDirty or getDiff. This is
>>> triggered either by an interceptor at the end of each request or by
>>> a batch process for less network jitter but less accuracy (but
>>> adequate) for fail over.
>>>
>>> As you can see, access time is not relevant here, nor does the
>>> Session API even know about clustering.
>>
>> How do you deal with access-time? I agree that your API doesn't know
>> about clustering, but you also can't do a client side or server side
>> redirect to the correct node; you must always migrate the session to
>> your request.
> it doesn't, there is no reason to. only the primary node can expire
> it, and when the primary manager, without knowing it is primary, does
> a sessionmap.remove() the LazyReplicatedMap removes it across the
> cluster.
> remember, when the session manager does,
> sessionmap.entrySet().iterator() it only gets session from this node,
> not the other nodes.
> so the implementation is completely transparent to the jetty programmer.
>
>>
>>> In tomcat we have separated out group communication into a separate
>>> module, we are implementing the LazyReplicatedHashMap right now just
>>> for this purpose.
>>
>> Cool. I'm interested to see what you come up with.
> I will keep you posted, maybe we could share the code/experience.
>
> Filip
>
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Hi Dain,
let me address the location, and show you how the location is completely
transparent.
The way the LazyReplicatedMap works is as follows:
1. Backup node fails -> primary node chooses a new backup node
2. Primary node fails -> since Tomcat doesn't know which node the user
will come to their
next http request, nothing is done.
When the user makes a request, and the session manager says
LazyMap.getSession(id) and that session is not yet on the server,
the lazymap will request the session from the backup server, load it
up, set this node as primary.
that is why it is called lazy, cause it wont load the session until
it is actually needed, and because it doesn't know what node will become
primary, this is decided by the load balancer. remember, that each node
knows where the session with Id=XXXX is located. they all carry the same
map, but only two carry the data (primary secondary).
on a false positive, the new primary node will cancel out the old one.
so you can have as many false positives as you want, but the more you
have the worse your performance will get :). that is why sticky lb is
important, but false positive is handled the same way as a crash except
that the old primary gets cancelled out.
the rest is inlined
>>
>> 1. Requirements to be implemented by the Session.java API
>> bool isDirty - (has the session changed in this request)
>> bool isDiffable - is the session able provide a diff
>> byte[] getSessionData() - returns the whole session
>> byte[] getSessionDiff() - optional, see isDiffable, resets the diff
>> data
>> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
>> changes from another node
>
> To throw you arguments back on you, why should my code be exposed to
> this level of detail :) From my perspective, I get a session and it
> is the Session API implementation's problem to figure out how to diff
> it, back it up, and migrate it.
>
exactly. the methods above is what is required from the servlet
container, not the webapp developer.
so if you are a jetty developer, you would implement the above methods.
This way, the jetty developer can optimize the serialization algorithm,
and locking (during diff creation), and your session will never be out
of date. in tomcat, we are making the getSessionDiff() a pluggable
algorithm, but it is implemented in the container, otherwise, just
serialization is too slow.
>> 2. Requirements to be implemented by the SessionManager.java API
>> void setSessionMap(HashMap map) - makes the map implementation
>> pluggable
>>
>> 3. And the key to this, is that we will have an implementation of a
>> LazyReplicatedHashMap
>> The key object in this map is the session Id.
>> The map entry object is an object that looks like this
>> ReplicatedEntry {
>> string id;//sessionid
>> bool isPrimary; //does this node hold the data
>> bool isBackup; //does this node hold backup data
>> Session session; //not null values for primary and backup nodes
>> Member primary; //information about the primary node
>> Member backup; //information about the backup node
>> }
>>
>> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>
> Why would anyone need to know this level of detail?
you don't and you will not, I just giving you some architectural insight
on how it works under the hood :)
>
>> So all the nodes will have the a sessionId,ReplicatedEntry
>> combinations in their session map. But only two nodes will have the
>> actual data.
>> This solution is for sticky LB only, but when failover happens, the
>> LB can pick any node as each node knows where to get the data.
>> The newly selected node, will keep the backup node or select a new
>> one, and do a publish to the entire cluster of the locations.
>
> I don't see anyway to deal with locking or the fact that servlet
> sessions are multi threaded (overlaping requests). How do you know
> when the session is not being used by anyone so you have a stable
> state for replication.
in tomcat we have an access counter, gets incremented when the request
comes in, and decremented when the request leaves. if the counter is 0,
lock the session and suck out the diff. or just lock it at the end of
each request on a periodic basis, regardless of what the counter is.
>
>> As you can see, all-to-all communications only happens when a Session
>> is (created|destroyed|failover). Other than that it is
>> primary-to-backup communication only, and this can be in terms of
>> diffs or entire sessions using the isDirty or getDiff. This is
>> triggered either by an interceptor at the end of each request or by a
>> batch process for less network jitter but less accuracy (but
>> adequate) for fail over.
>>
>> As you can see, access time is not relevant here, nor does the
>> Session API even know about clustering.
>
> How do you deal with access-time? I agree that your API doesn't know
> about clustering, but you also can't do a client side or server side
> redirect to the correct node; you must always migrate the session to
> your request.
it doesn't, there is no reason to. only the primary node can expire it,
and when the primary manager, without knowing it is primary, does a
sessionmap.remove() the LazyReplicatedMap removes it across the cluster.
remember, when the session manager does,
sessionmap.entrySet().iterator() it only gets session from this node,
not the other nodes.
so the implementation is completely transparent to the jetty programmer.
>
>> In tomcat we have separated out group communication into a separate
>> module, we are implementing the LazyReplicatedHashMap right now just
>> for this purpose.
>
> Cool. I'm interested to see what you come up with.
I will keep you posted, maybe we could share the code/experience.
Filip
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
Filip,
This is good feedback; I wasn't aware of the details on what Tomcat
has done in this area.
We added concept of location to the Session APIs to address a few of
the weird and surprisingly common use cases.
1) Unreliable load balancer
In this case, the load balancer is not 100% and sometimes delivers
requests to the wrong node.
The solution to the first part is to allow the container to discover
the actual location of the session and do a client or server side
redirect to the correct node.
2) False positive on server failure
Load balancer decides that the machine has died and picks a new
random node for the request.
This requires either moving the session to the local machine or
sending a message to the load balancer informing it of the correct
location for the request.
3) Geronimo based load balancer
A Geronimo node sits in front of a group of Geronimo server, receives
all requests and directs them to the correct node.
In this case, the server needs to know the location of the session
and proxies the request to the correct node.
4) Smart Balancing
Some force behind the scenes (under the covers of the APIs) is
manipulating the load directly by migrating sessions. The clients
may not be aware of the migration and send requests to the wrong node.
This is very similar to Case 2, except in this case we need a way to
inform the client of the correct location of the session. The
pending request can simply be proxied on to the correct node with a
side-band message that the next request should go to a different
node, or we could do a client side redirect.
As you can, see all of the use cases we thought of require the
knowledge of the session location. Now, I am willing to admit that
this may be a "golden hammer" solution, so I'm open to any other ways
to implement these features without having to know session location.
I have some comments inline about the session api you present.
-dain
On Mar 3, 2006, at 7:00 AM, Filip Hanik - Dev Lists wrote:
> gentlemen, not a committer here, but wanted to share some thoughts.
>
> in my opinion, the Session API should not have to know about
> clustering or session replication, nor should it need to worry
> about location.
> the clustering API should take care of all of that.
>
> the solution that we plan to implement for Tomcat is fairly
> straight forward. Let me see if I can give an idea of how the API
> shouldn't need to worry, its a little lengthy, but it shows that
> the Session and the SessionManager need to know zero about
> clustering or session locations. (this is only one solution, and
> other solutions should demonstrate the same point, SessionAPI need
> to know nothing about clustering or session locations)
>
> 1. Requirements to be implemented by the Session.java API
> bool isDirty - (has the session changed in this request)
> bool isDiffable - is the session able provide a diff
> byte[] getSessionData() - returns the whole session
> byte[] getSessionDiff() - optional, see isDiffable, resets the
> diff data
> void setSessionDiff(byte[] diff) - optional, see isDiffable,
> apply changes from another node
To throw you arguments back on you, why should my code be exposed to
this level of detail :) From my perspective, I get a session and it
is the Session API implementation's problem to figure out how to diff
it, back it up, and migrate it.
> 2. Requirements to be implemented by the SessionManager.java API
> void setSessionMap(HashMap map) - makes the map implementation
> pluggable
>
> 3. And the key to this, is that we will have an implementation of a
> LazyReplicatedHashMap
> The key object in this map is the session Id.
> The map entry object is an object that looks like this
> ReplicatedEntry {
> string id;//sessionid
> bool isPrimary; //does this node hold the data
> bool isBackup; //does this node hold backup data
> Session session; //not null values for primary and backup nodes
> Member primary; //information about the primary node
> Member backup; //information about the backup node
> }
>
> The LazyReplicatedHashMap overrides get(key) and put(id,session)
Why would anyone need to know this level of detail?
> So all the nodes will have the a sessionId,ReplicatedEntry
> combinations in their session map. But only two nodes will have the
> actual data.
> This solution is for sticky LB only, but when failover happens, the
> LB can pick any node as each node knows where to get the data.
> The newly selected node, will keep the backup node or select a new
> one, and do a publish to the entire cluster of the locations.
I don't see anyway to deal with locking or the fact that servlet
sessions are multi threaded (overlaping requests). How do you know
when the session is not being used by anyone so you have a stable
state for replication.
> As you can see, all-to-all communications only happens when a
> Session is (created|destroyed|failover). Other than that it is
> primary-to-backup communication only, and this can be in terms of
> diffs or entire sessions using the isDirty or getDiff. This is
> triggered either by an interceptor at the end of each request or by
> a batch process for less network jitter but less accuracy (but
> adequate) for fail over.
>
> As you can see, access time is not relevant here, nor does the
> Session API even know about clustering.
How do you deal with access-time? I agree that your API doesn't know
about clustering, but you also can't do a client side or server side
redirect to the correct node; you must always migrate the session to
your request.
> In tomcat we have separated out group communication into a separate
> module, we are implementing the LazyReplicatedHashMap right now
> just for this purpose.
Cool. I'm interested to see what you come up with.
-dain
Re: [wadi-dev] Re: Session Policy was: heads up: initial contribution
of a client API to session state management for OpenEJB, ServiceMix, Lingo
and Tuscany
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Filip Hanik - Dev Lists wrote:
> Hey Jules,
> thanks for commenting, I will pop in on codehaus devlists.
> The lazy replicated map supports more than one backup node, with a
> very small tweak in just one method, you can change it to be N number
> of backup nodes. N being configurable, just a matter of getting the
> conf param down to the impl level.
>
nice :-) - we are just getting the first cut of our in-vm replication
service in place - it is similarly parameterisable, with a pluggable
strategy for selecting suitable replication partners...
> Apache Tribes, as I like to nickname the Tomcat group communication
> protocol, has an implementation at
> http://svn.apache.org/viewcvs.cgi/tomcat/container/tc5.5.x/modules/groupcom/
>
> including the LazyReplicatedMap and a MapDemo (you're gonna be awed by
> my Swing skills).
Hmmm.. - I shall need to take the time to look at this.
>
> I am also in the place of implementing a regular ReplicatedMap, to use
> for context attribute replication, a feature sought after.
Yes - I have shied away from supporting distributed context attributes,
since they are not specced - but, you never know :-)
>
> I will subscribe to the WADI list and we can continue over there re:
> session management.
I look forward to seeing you over there,
Jules
>
> Filip
>
>
>
> Jules Gosnell wrote:
>
>> Filip Hanik - Dev Lists wrote:
>>
>>> gentlemen, not a committer here, but wanted to share some thoughts.
>>>
>>> in my opinion, the Session API should not have to know about
>>> clustering or session replication, nor should it need to worry about
>>> location.
>>> the clustering API should take care of all of that.
>>>
>> We are 100% in agreement here, Filip.
>>
>>> the solution that we plan to implement for Tomcat is fairly straight
>>> forward. Let me see if I can give an idea of how the API shouldn't
>>> need to worry, its a little lengthy, but it shows that the Session
>>> and the SessionManager need to know zero about clustering or session
>>> locations. (this is only one solution, and other solutions should
>>> demonstrate the same point, SessionAPI need to know nothing about
>>> clustering or session locations)
>>>
>>> 1. Requirements to be implemented by the Session.java API
>>> bool isDirty - (has the session changed in this request)
>>> bool isDiffable - is the session able provide a diff
>>> byte[] getSessionData() - returns the whole session
>>> byte[] getSessionDiff() - optional, see isDiffable, resets the
>>> diff data
>>> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
>>> changes from another node
>>>
>> So, delta-ed sessions, at whole session or attribute granularity ?
>> and when will you be sending the deltas - immediately, end of
>> request[-group], pluggable strategies ?
>>
>>> 2. Requirements to be implemented by the SessionManager.java API
>>> void setSessionMap(HashMap map) - makes the map implementation
>>> pluggable
>>>
>>> 3. And the key to this, is that we will have an implementation of a
>>> LazyReplicatedHashMap
>>> The key object in this map is the session Id.
>>> The map entry object is an object that looks like this
>>> ReplicatedEntry {
>>> string id;//sessionid
>>> bool isPrimary; //does this node hold the data
>>> bool isBackup; //does this node hold backup data
>>> Session session; //not null values for primary and backup nodes
>>> Member primary; //information about the primary node
>>> Member backup; //information about the backup node
>>> }
>>>
>>> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>>>
>> interesting...
>>
>>> So all the nodes will have the a sessionId,ReplicatedEntry
>>> combinations in their session map. But only two
>>
>>
>> two is a fixed number or deploy-time parameter ?
>>
>>> nodes will have the actual data.
>>> This solution is for sticky LB only, but when failover happens, the
>>> LB can pick any node as each node knows where to get the data.
>>> The newly selected node, will keep the backup node or select a new
>>> one, and do a publish to the entire cluster of the locations.
>>>
>>> As you can see, all-to-all communications only happens when a
>>> Session is (created|destroyed|failover). Other than that it is
>>> primary-to-backup communication only, and this can be in terms of
>>> diffs or entire sessions using the isDirty or getDiff. This is
>>> triggered either by an interceptor at the end of each request or by
>>> a batch process for less network jitter but less accuracy (but
>>> adequate) for fail over.
>>
>>
>> I see - that answers my question about when replication occurs :-)
>>
>>>
>>> As you can see, access time is not relevant here, nor does the
>>> Session API even know about clustering.
>>
>>
>> yes !
>>
>>>
>>> In tomcat we have separated out group communication into a separate
>>> module, we are implementing the LazyReplicatedHashMap right now just
>>> for this purpose.
>>>
>>> positive thoughts, criticism and bashing are all welcome :)
>>
>>
>> This approach has much more in common with WADI's - in fact there is
>> lot of synergy here. I think the WADI and TC clustering teams could
>> learn a lot from each other. I would be very interested in sitting
>> down with you Filip and having a long chat about session management.
>> Do you have a Tomcat clustering-specific list that I could jump onto
>> ? You might be interested in popping in on dev@wadi.codehaus.org and
>> learning a little more about WADI ?
>>
>> regards,
>>
>> Jules
>>
>>>
>>> Filip
>>>
>>>
>>>
>>
>>
>>
>>
>
--
"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.
**********************************/
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Hey Jules,
thanks for commenting, I will pop in on codehaus devlists.
The lazy replicated map supports more than one backup node, with a very
small tweak in just one method, you can change it to be N number of
backup nodes. N being configurable, just a matter of getting the conf
param down to the impl level.
Apache Tribes, as I like to nickname the Tomcat group communication
protocol, has an implementation at
http://svn.apache.org/viewcvs.cgi/tomcat/container/tc5.5.x/modules/groupcom/
including the LazyReplicatedMap and a MapDemo (you're gonna be awed by
my Swing skills).
I am also in the place of implementing a regular ReplicatedMap, to use
for context attribute replication, a feature sought after.
I will subscribe to the WADI list and we can continue over there re:
session management.
Filip
Jules Gosnell wrote:
> Filip Hanik - Dev Lists wrote:
>
>> gentlemen, not a committer here, but wanted to share some thoughts.
>>
>> in my opinion, the Session API should not have to know about
>> clustering or session replication, nor should it need to worry about
>> location.
>> the clustering API should take care of all of that.
>>
> We are 100% in agreement here, Filip.
>
>> the solution that we plan to implement for Tomcat is fairly straight
>> forward. Let me see if I can give an idea of how the API shouldn't
>> need to worry, its a little lengthy, but it shows that the Session
>> and the SessionManager need to know zero about clustering or session
>> locations. (this is only one solution, and other solutions should
>> demonstrate the same point, SessionAPI need to know nothing about
>> clustering or session locations)
>>
>> 1. Requirements to be implemented by the Session.java API
>> bool isDirty - (has the session changed in this request)
>> bool isDiffable - is the session able provide a diff
>> byte[] getSessionData() - returns the whole session
>> byte[] getSessionDiff() - optional, see isDiffable, resets the diff
>> data
>> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
>> changes from another node
>>
> So, delta-ed sessions, at whole session or attribute granularity ? and
> when will you be sending the deltas - immediately, end of
> request[-group], pluggable strategies ?
>
>> 2. Requirements to be implemented by the SessionManager.java API
>> void setSessionMap(HashMap map) - makes the map implementation
>> pluggable
>>
>> 3. And the key to this, is that we will have an implementation of a
>> LazyReplicatedHashMap
>> The key object in this map is the session Id.
>> The map entry object is an object that looks like this
>> ReplicatedEntry {
>> string id;//sessionid
>> bool isPrimary; //does this node hold the data
>> bool isBackup; //does this node hold backup data
>> Session session; //not null values for primary and backup nodes
>> Member primary; //information about the primary node
>> Member backup; //information about the backup node
>> }
>>
>> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>>
> interesting...
>
>> So all the nodes will have the a sessionId,ReplicatedEntry
>> combinations in their session map. But only two
>
> two is a fixed number or deploy-time parameter ?
>
>> nodes will have the actual data.
>> This solution is for sticky LB only, but when failover happens, the
>> LB can pick any node as each node knows where to get the data.
>> The newly selected node, will keep the backup node or select a new
>> one, and do a publish to the entire cluster of the locations.
>>
>> As you can see, all-to-all communications only happens when a Session
>> is (created|destroyed|failover). Other than that it is
>> primary-to-backup communication only, and this can be in terms of
>> diffs or entire sessions using the isDirty or getDiff. This is
>> triggered either by an interceptor at the end of each request or by a
>> batch process for less network jitter but less accuracy (but
>> adequate) for fail over.
>
> I see - that answers my question about when replication occurs :-)
>
>>
>> As you can see, access time is not relevant here, nor does the
>> Session API even know about clustering.
>
> yes !
>
>>
>> In tomcat we have separated out group communication into a separate
>> module, we are implementing the LazyReplicatedHashMap right now just
>> for this purpose.
>>
>> positive thoughts, criticism and bashing are all welcome :)
>
> This approach has much more in common with WADI's - in fact there is
> lot of synergy here. I think the WADI and TC clustering teams could
> learn a lot from each other. I would be very interested in sitting
> down with you Filip and having a long chat about session management.
> Do you have a Tomcat clustering-specific list that I could jump onto ?
> You might be interested in popping in on dev@wadi.codehaus.org and
> learning a little more about WADI ?
>
> regards,
>
> Jules
>
>>
>> Filip
>>
>>
>>
>
>
>
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Filip Hanik - Dev Lists wrote:
> gentlemen, not a committer here, but wanted to share some thoughts.
>
> in my opinion, the Session API should not have to know about
> clustering or session replication, nor should it need to worry about
> location.
> the clustering API should take care of all of that.
>
We are 100% in agreement here, Filip.
> the solution that we plan to implement for Tomcat is fairly straight
> forward. Let me see if I can give an idea of how the API shouldn't
> need to worry, its a little lengthy, but it shows that the Session and
> the SessionManager need to know zero about clustering or session
> locations. (this is only one solution, and other solutions should
> demonstrate the same point, SessionAPI need to know nothing about
> clustering or session locations)
>
> 1. Requirements to be implemented by the Session.java API
> bool isDirty - (has the session changed in this request)
> bool isDiffable - is the session able provide a diff
> byte[] getSessionData() - returns the whole session
> byte[] getSessionDiff() - optional, see isDiffable, resets the diff
> data
> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
> changes from another node
>
So, delta-ed sessions, at whole session or attribute granularity ? and
when will you be sending the deltas - immediately, end of
request[-group], pluggable strategies ?
> 2. Requirements to be implemented by the SessionManager.java API
> void setSessionMap(HashMap map) - makes the map implementation
> pluggable
>
> 3. And the key to this, is that we will have an implementation of a
> LazyReplicatedHashMap
> The key object in this map is the session Id.
> The map entry object is an object that looks like this
> ReplicatedEntry {
> string id;//sessionid
> bool isPrimary; //does this node hold the data
> bool isBackup; //does this node hold backup data
> Session session; //not null values for primary and backup nodes
> Member primary; //information about the primary node
> Member backup; //information about the backup node
> }
>
> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>
interesting...
> So all the nodes will have the a sessionId,ReplicatedEntry
> combinations in their session map. But only two
two is a fixed number or deploy-time parameter ?
> nodes will have the actual data.
> This solution is for sticky LB only, but when failover happens, the LB
> can pick any node as each node knows where to get the data.
> The newly selected node, will keep the backup node or select a new
> one, and do a publish to the entire cluster of the locations.
>
> As you can see, all-to-all communications only happens when a Session
> is (created|destroyed|failover). Other than that it is
> primary-to-backup communication only, and this can be in terms of
> diffs or entire sessions using the isDirty or getDiff. This is
> triggered either by an interceptor at the end of each request or by a
> batch process for less network jitter but less accuracy (but adequate)
> for fail over.
I see - that answers my question about when replication occurs :-)
>
> As you can see, access time is not relevant here, nor does the Session
> API even know about clustering.
yes !
>
> In tomcat we have separated out group communication into a separate
> module, we are implementing the LazyReplicatedHashMap right now just
> for this purpose.
>
> positive thoughts, criticism and bashing are all welcome :)
This approach has much more in common with WADI's - in fact there is lot
of synergy here. I think the WADI and TC clustering teams could learn a
lot from each other. I would be very interested in sitting down with you
Filip and having a long chat about session management. Do you have a
Tomcat clustering-specific list that I could jump onto ? You might be
interested in popping in on dev@wadi.codehaus.org and learning a little
more about WADI ?
regards,
Jules
>
> Filip
>
>
>
--
"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.
**********************************/
Re: Session Policy was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly straight
forward. Let me see if I can give an idea of how the API shouldn't need
to worry, its a little lengthy, but it shows that the Session and the
SessionManager need to know zero about clustering or session locations.
(this is only one solution, and other solutions should demonstrate the
same point, SessionAPI need to know nothing about clustering or session
locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry combinations
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one,
and do a publish to the entire cluster of the locations.
As you can see, all-to-all communications only happens when a Session is
(created|destroyed|failover). Other than that it is primary-to-backup
communication only, and this can be in terms of diffs or entire sessions
using the isDirty or getDiff. This is triggered either by an interceptor
at the end of each request or by a batch process for less network jitter
but less accuracy (but adequate) for fail over.
As you can see, access time is not relevant here, nor does the Session
API even know about clustering.
In tomcat we have separated out group communication into a separate
module, we are implementing the LazyReplicatedHashMap right now just for
this purpose.
positive thoughts, criticism and bashing are all welcome :)
Filip
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 1, 2006, at 11:55 PM, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>
>>> Policy
>>> ======
>
>>> So firstly we need SessionLocatoin.moveto(Server server),
>>
>> I'm confused. Why would we need that?
>
> There is an API to pull a session to a local node, but there
> is no API to push a session to a specific node.
>
> The use-case for the later if you have a load balancer that is
> a bit erratic and may scatter requests around a bit (think mod_jk
> after it has lost a node).
>
> If you have a policy where every node that receives a request
> pulls the session to it, then the session will expensively bounce
> around the cluster.
This is something we talked about, and decided that no matter what
you put in your system, you can always end up with a nomadic
session. The solution to this is to slow the migration of the
session so it doesn't have a negative impact on the system.
Basically we implement a "don't move more often then every x minutes"
policy in the system by letting the system that owns a session to
refuse to let it be moved.
> Instead you can have a policy where you proxy (or redirect) the
> request to the node where the session is. This work fine, but at
> the cost of a proxy. If all or most of the requests are being
> sent to a specific node, then the session itself should be
> able to decide to migrate to that node: "I've been receiving
> most of my requests via node 7, so I think I'll move there".
>
> Thus we need a moveTo.
>
> I think a moveTo will also be useful for implementing shutdown
> policies, where you want to gently take a node out of a cluster.
> The policy should be able to be written independently of impl.
I see the problem differently. I think the node that is proxying is
paying the cost of the proxy. If that node, decides that proxying is
getting two expensive, it can choose to moveLocally(). I see no need
to have a push function.
>>> but more importantly, when we are redirecting or proxying
>>> requests, it would be good to be able to attach impl
>>> specific meta data to those requests. So the HTTP tier
>>> needs to be able to ask a SessionLocation for an opaque
>>> blob of meta data associated with a request and to be
>>> able to set that meta data when it recieves it.
>>
>>
>> Huh? Redirect would be dependent on the web container so this
>> would be
>> a detail for the web container to deal with. The session apis, only
>> says, "the session data is on server x". How the web container gets
>> the request to server x is it's problem.
>
> I totally agree that it is the web-servers problem to
> move a request from one node to the other node.
>
> But I think there will be a need for some opaque impl
> specific data to be sent with that request - so the
> impl can coordinate it's actions.
>
> At the very least, it would be good for a request arriving
> on node x to be able to carry the opaque message: "I came from
> node z". It is easy for the web container to add such messages,
> but there is no way they can be passed to the policy impl.
>
>
> anyway... this is all getting very abstract... I think
> we(I) can let this slide a bit until there are some concrete
> policy implementation we can play with.
Cool, I was getting really lost amyway :)
-dain
Session Policy was: heads up: initial contribution of a client API
to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
>> Policy
>> ======
>> So firstly we need SessionLocatoin.moveto(Server server),
>
> I'm confused. Why would we need that?
There is an API to pull a session to a local node, but there
is no API to push a session to a specific node.
The use-case for the later if you have a load balancer that is
a bit erratic and may scatter requests around a bit (think mod_jk
after it has lost a node).
If you have a policy where every node that receives a request
pulls the session to it, then the session will expensively bounce
around the cluster.
Instead you can have a policy where you proxy (or redirect) the
request to the node where the session is. This work fine, but at
the cost of a proxy. If all or most of the requests are being
sent to a specific node, then the session itself should be
able to decide to migrate to that node: "I've been receiving
most of my requests via node 7, so I think I'll move there".
Thus we need a moveTo.
I think a moveTo will also be useful for implementing shutdown
policies, where you want to gently take a node out of a cluster.
The policy should be able to be written independently of impl.
>> but more importantly, when we are redirecting or proxying
>> requests, it would be good to be able to attach impl
>> specific meta data to those requests. So the HTTP tier
>> needs to be able to ask a SessionLocation for an opaque
>> blob of meta data associated with a request and to be
>> able to set that meta data when it recieves it.
>
>
> Huh? Redirect would be dependent on the web container so this would be
> a detail for the web container to deal with. The session apis, only
> says, "the session data is on server x". How the web container gets
> the request to server x is it's problem.
I totally agree that it is the web-servers problem to
move a request from one node to the other node.
But I think there will be a need for some opaque impl
specific data to be sent with that request - so the
impl can coordinate it's actions.
At the very least, it would be good for a request arriving
on node x to be able to carry the opaque message: "I came from
node z". It is easy for the web container to add such messages,
but there is no way they can be passed to the policy impl.
anyway... this is all getting very abstract... I think
we(I) can let this slide a bit until there are some concrete
policy implementation we can play with.
cheers
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by James Strachan <ja...@gmail.com>.
On 3 Mar 2006, at 14:41, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>> Object value = session.getState("web:/context-" + name);
>
> Ok I get it now.
>
> Don't have a deep - hard to replicate - structure.
> Have a flat structure, but with a scoped name space!
>
> I think this approach solves a lot of issues and probably
> reduces the need for extra API.
>
> For example, perhaps we could communicate maxIdleTimes via
> naming conventions rather than API:
>
> session.putState("session:maxIdleTimeMs",new Integer(60000));
>
> I still don't know if this approach can help with event notification,
> but I defer that until I have a quasi-working session manager against
> the API.
Agreed.
Maybe the WebSession API should have a typesafe API for things that a
servlet engine needs to do like the max idle times and the like; then
we could use the above as one implementation & if we don't like it we
could change it later without having to change the Jetty & Tomcat
integration code.
James
-------
http://radio.weblogs.com/0112098/
Re: Session API, was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> My guess is we're going to need to add an event notification system to
> the Session APIs. What do you think about just crib off of the servlet
> ones. I think we could just smash the three session listener
> interfaces into something like this:
>
> public interface SessionListener extends Listener {
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void attributeAdded(SessionEvent event);
> void attributeRemoved(SessionEvent event);
> void attributeRemoved(SessionEvent event);
I think you mean:
void attributeReplaced(SessionEvent event);
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void sessionCreated(SessionEvent event)
> void sessionDestroyed(SessionEvent event)
> }
>
> public class SessionEvent extends Event {
> Session getSession();
> String getName();
> String getValue();
> }
>
> We would bind a listener with a method on the Locator:
>
> void addSessionListener(SessionListener listener);
> void removeSessionListener(SessionListener listener);
that would certainly do it - the only change I'd like to see
is that the SessionEvent is
public class SessionEvent extends Event {
Session getSession();
String getName();
String getOldValue();
String getNewValue();
}
As it is confusing for remove and replace what getValue() returns.
Also as the bound/unbound events are actually called on the
value itself, you need both old and new values so you can call
unbind and bind during a replace.
cheers
Re: Session API, was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> My guess is we're going to need to add an event notification system to
> the Session APIs. What do you think about just crib off of the servlet
> ones. I think we could just smash the three session listener
> interfaces into something like this:
>
> public interface SessionListener extends Listener {
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void attributeAdded(SessionEvent event);
> void attributeRemoved(SessionEvent event);
> void attributeRemoved(SessionEvent event);
I think you mean:
void attributeReplaced(SessionEvent event);
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void sessionCreated(SessionEvent event)
> void sessionDestroyed(SessionEvent event)
> }
>
> public class SessionEvent extends Event {
> Session getSession();
> String getName();
> String getValue();
> }
>
> We would bind a listener with a method on the Locator:
>
> void addSessionListener(SessionListener listener);
> void removeSessionListener(SessionListener listener);
that would certainly do it - the only change I'd like to see
is that the SessionEvent is
public class SessionEvent extends Event {
Session getSession();
String getName();
String getOldValue();
String getNewValue();
}
As it is confusing for remove and replace what getValue() returns.
Also as the bound/unbound events are actually called on the
value itself, you need both old and new values so you can call
unbind and bind during a replace.
cheers
Re: Summary?
Posted by Greg Wilkins <gr...@mortbay.com>.
David Blevins wrote:
> For myself and others can someone post a real short summary of where
> this conversation is at?
For my part.....
I agree with Jules that the session API (really a state API)
and the policy API should be considered separately.
My main concern at the moment is the state API, as I would really
like to have a single SessionManager implementation for Jetty that
would be responsible for the web aspects of session management,
but would delegate via the API to an arbitrary state store (be
in clustered, persistent or whatever).
So I see there is a conflict between a KISS one-size fits all
state API and something that will support all the good, bad and
ugly behaviour that a compliant servlet container needs from
a session state store. But Dain has convinced me that by
using a structured name space, I should be able to address most
of the issues of cross context dispatch. He also agrees that
we could add an API for notification that would support the web
requirements.
With that, I'm happy to go ahead and write a session manager
based on the state aspects of this API. I'm just waiting for
(and Jan may help with) a maven2 build and I'll start the
jetty 6 module and give the API a try.
But I've also had some long conversations with Jules about
both the state and the policy aspects of the API. I can see
his concerns about the structured name space approach making
it difficult to efficiently implement all clustering configurations,
but I can't see a way around that without adding a deep API that
supports multiple state stores for a single session ID. That
is probably very web specific and would complicate other uses
of the API. I am hoping that the non-efficient configurations
are the 1% case and not the 99% case.
With regards to the policy API - I'm not sure what I think
now. Jules has almost convinced me for the need of a standard
invocation API... which is an API to the policy implementation.
The current API, is more something that a policy implementation
can use the manipulate state.
If we do standardize a way to invoke clustering policy, then
I'm not sure that we need the current API aspects about location
and session movement. If the same implementation gives you a
state store and a policy implementation, who cares how the
policy manipulates the state store!
But policy is less my concern that state... so I still plan
to proceed with a session manager implementation and then we
will have a play ground to experiment with policy.
cheers
Summary?
Posted by David Blevins <da...@visi.com>.
For myself and others can someone post a real short summary of where
this conversation is at?
-David
Re: Summary? was: Session API....
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/
Re: Summary? was: Session API....
Posted by Hiram Chirino <hi...@hiramchirino.com>.
>
> 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.
--
Regards,
Hiram
Re: Summary?
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Dain Sundstrom wrote:
> On Mar 13, 2006, at 6:54 PM, David Blevins wrote:
>
>> On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
>>
>>> Is it possible for one client to pass the handle of an SFSB to
>>> another ? Does the spec touch on this ? Does it ever happen ?
>>
>>
>> I know that per spec, the client identity cannot change mid-
>> transaction. Aside from that we allow it.
>
>
> My experience is that a SFSB is almost always tied to a single client
> (e.g. user). I have seen a few weird pieces of code that passed
> SFSBs between clients, but the reason I was looking at them was
> because that didn't work reliably. This is largely due to
> EJB2.1:7.5.8 which states:
>
> Clients are not allowed to make concurrent calls to a stateful
> session object. If a client-invoked business method is in progress on
> an instance when another client-invoked call, from the same or
> different client, arrives at the same instance of a stateful session
> bean class, the container may throw the java.rmi.RemoteException to
> the second client[7] if the client is a remote client, or the
> javax.ejb.EJBException if the client is a local client. This
> restriction does not apply to a stateless session bean because the
> container routes each request to a different instance of the session
> bean class.
>
interesting - thanks.
Jules
> For the weird cases, we could add an option in the EJB container to
> not keep a specific SFSB deployment in the client session.
>
> -dain
--
"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.
**********************************/
Re: Summary?
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 13, 2006, at 6:54 PM, David Blevins wrote:
> On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
>
>> Is it possible for one client to pass the handle of an SFSB to
>> another ? Does the spec touch on this ? Does it ever happen ?
>
> I know that per spec, the client identity cannot change mid-
> transaction. Aside from that we allow it.
My experience is that a SFSB is almost always tied to a single client
(e.g. user). I have seen a few weird pieces of code that passed
SFSBs between clients, but the reason I was looking at them was
because that didn't work reliably. This is largely due to
EJB2.1:7.5.8 which states:
Clients are not allowed to make concurrent calls to a stateful
session object. If a client-invoked business method is in progress on
an instance when another client-invoked call, from the same or
different client, arrives at the same instance of a stateful session
bean class, the container may throw the java.rmi.RemoteException to
the second client[7] if the client is a remote client, or the
javax.ejb.EJBException if the client is a local client. This
restriction does not apply to a stateless session bean because the
container routes each request to a different instance of the session
bean class.
For the weird cases, we could add an option in the EJB container to
not keep a specific SFSB deployment in the client session.
-dain
Re: Summary?
Posted by Jules Gosnell <ju...@coredevelopers.net>.
lichtner wrote:
>On Tue, 14 Mar 2006, David Blevins wrote:
>
>
>
>>Provisioning of the actual stateful session bean keys is easy to
>>isolate, but as I say inventing a client id that you could use as
>>part of a stateful session bean's id is not easy.
>>
>>
>
>Would it be enough to generate a cluster-wide unique id?
>
>
As long as you could map the SFSB back to the ID of the 'User' or
SuperSession, to look that up, then look up your SFSB within this with
whatever key you liked, I think you would be OK with the proposed API -
but you would have to check with James/Dain to be sure...
I haven't decided yet on exactly how I want to implement this in WADI....
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.
**********************************/
Re: Summary?
Posted by lichtner <li...@bway.net>.
On Tue, 14 Mar 2006, David Blevins wrote:
> Provisioning of the actual stateful session bean keys is easy to
> isolate, but as I say inventing a client id that you could use as
> part of a stateful session bean's id is not easy.
Would it be enough to generate a cluster-wide unique id?
Re: Summary?
Posted by Jules Gosnell <ju...@coredevelopers.net>.
David Blevins wrote:
>
> On Mar 14, 2006, at 12:55 AM, Jules Gosnell wrote:
>
>> David Blevins wrote:
>>
>>>
>>> On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
>>>
>>>> David Blevins wrote:
>>>>
>>>>> Sorry, was referring to this thread. Seems like it's winding
>>>>> down and just looking for a clear idea of what the current
>>>>> thinking is.
>>>>>
>>>> David,
>>>>
>>>> since you are here - a few SFSB questions...
>>>>
>>>> what provisions does the EJB spec make for timing out of SFSBs,
>>>> if any ? what metadata does this require associated with each
>>>> session ?
>>>
>>>
>>>
>>> What I can recal is that you can't passivate a stateful bean in
>>> mid- transaction. You must activate a stateful bean if a client
>>> attempts to invoke it and the instance has not yet been timed
>>> out. And unlike Entities, Stateful session bean data isn't
>>> required to survive a server crash or restart.
>>>
>>>> what provisions/requirements over and above these does OpenEJB
>>>> make/ have ?
>>>> Aside from lifecycle management, retrieval and timing out, what
>>>> other requirements might OpenEJB have for SFSB management ?
>>>
>>>
>>>
>>> Nothing I can think of. Maybe you are looking for something very
>>> specific.
>>
>>
>> I'm wondering how SFSBs are timed out. Does the spec describe this
>> or is it container-specific ? Is the time-to-live on a per bean
>> instance, type or container-wide basis ? I'm trying to get a
>> clearer picture of how we might unify web and ejb session
>> lifecycles, so that they can be managed in a single component,
>
>
> The most specific the spec is on timing out is that "the Deployer
> configures" it. It's completely implementation specific and it's
> pretty much just required that someone be allowed to set it, whatever
> it is and however it may work.
>
>>>> Are Local SFSBs to be considered Serialisable/Passivatable/
>>>> Migratable or not ?
>>>
>>>
>>>
>>> I think you may be thinking that a client using a Local vs Remote
>>> interface to access a stateful bean has a different impact on the
>>> stateful bean's lifecycle. The lifecycle is the same regardless
>>> of how a client accesses it. In other words, there is no such
>>> thing as a local or remote bean, just local or remote reference to
>>> beans.
>>
>>
>> I'm thinking that use of a Local interface relaxes the constraint on
>> params being passed through it being Serialisable. This implies that
>> the SFSB the other end may be asked to store non-Serialisable data.
>> If it does, this would preclude it from being involved in operations
>> like passivation and migration....? But, if the activate/ passivate
>> part of the lifecycle is required of Local SFSBs as well, then
>> perhaps this is not an issue ?
>
>
> Again, wether the stateful bean is accessed via Local vs Remote
> interface has zero affect or implications on the bean instance and
> it's lifecycle rules. In all cases it's the bean's responsibility
> to ensure that it's non-transient fields are serializable or one of
> the container-provided objects (datasource refs, UserTransaction,
> home objects, local or remote objects, etc).
>
>>>> Would it be simple to change OpenEJB to use an SFSB handle that
>>>> included an ID to a 'SuperSession' (Object containing all Session
>>>> objects pertaining to a single client for a given Server) along
>>>> with an ID to particular 'SubSession' (The SFSB itself) within
>>>> this 'SuperSession', instead of whatever scheme you currently use ?
>>>
>>>
>>>
>>> That wouldn't be simple as we don't have any concept of
>>> provisioning client ids aside from the optional security identity
>>> associated with incoming calls. In general the spec isn't really
>>> strict on the server's view of a client, it's more focused on a
>>> client's view of a bean (e.g. server). That is to say, beans have
>>> strict and spelled out identity rules whereas client's do not.
>>>
>>> We could invent a universal client id concept but it would be a
>>> fair amount of work to reconcile that concept across the various
>>> ways people can invoke stateful beans; IIOP+IDL, IIOP+Remote
>>> interface, Custom protocol + Remote interface, Local interface.
>>> Using just Local interfaces, is the client id:
>>> - The id of the servlet or ejb
>>> - The id of the war or ejb-jar
>>> - The id of the ear (if there is one)
>>> - The id of the VM
>>>
>>> Remote interfaces really get you in trouble as they have the same
>>> questions, plus they can be invoked by j2ee app clients as well as
>>> non-j2ee java clients, or even non-java clients via IDL/IIOP.
>>>
>> exactly - there is a can of worms here, which I think we are
>> glossing over...
>>
>> I've been giving some thought to how SFSB keys/ids/handles might
>> work in a way that would allow them them to be colocated in a
>> SuperSession... It is tricky because of the multiple ways in which
>> they might be accessed. I think this needs careful thought and
>> discussion. If provisioning of these keys is not easily isolated
>> from the rest of OpenEJB then I think we will have problems here...
>
>
> Provisioning of the actual stateful session bean keys is easy to
> isolate, but as I say inventing a client id that you could use as
> part of a stateful session bean's id is not easy.
>
OK - great - thanks for all the clarifications...
>>> I guess I'm not sure at what level you are thinking when you say
>>> the word "client" or what you'd be looking to get out of the concept.
>>
>>
>> anyone addressing one or more SFSBs via the EJB containers services.
>
>
> I was hoping for something more concrete and not more abstract :)
> "Anyone" is way too vague to be useful. As i say, what is most
> effective for your purposes? At least a finger in the wind would be
> helpful to get my brain around what level you may need. I.e. is a
> client a component, or the application the component resides in, or
> the VM the application resides in, or the user driving the
> application...?
Ah - sorry, I think I see what you are driving at... - I was talking
about 'clients' in the context of Session colocation - so I should have
been more explicit and said 'User'.
The idea is one that I have had in mind for some time and the proposed
Session API has adopted - that Geronimo should try to maintain the
colocation of Sessions that are related. So if a WebSession moves from
box A to box B we may want to move related SFSBs as well... By storing
all related Sessions in the same object, we can ensure that this happens.
The problem will be deciding which sessions to group together.
Provided that there was only one usecase, things would be pretty
straightforward - in a simple scenario, SFSBs could just be grouped by
User. However when we get mixed usecases, things become more tricky -
perhaps instances of the same SFSB being used by both external
fat-clients aswell as threads from the web-container... Perhaps there is
a way to map threads related to a particular WebSession in the web tier
to a particular unique 'User' in the EJB tier ? Where cross-context
dispatch needs to be supported in the web tier, rather than a single
WebSession mapping to an EJB User, all WebSessions using the same
SessionID will need to map to the same 'User' - I guess we just need to
ensure that we can identify colocation relationships in each tier and
map them to a common representation across all tiers... whether that
representation is a User or something else is an open question...
I haven't given this serious thought yet - just flagged it as requiring
further consideration...
My understanding is that the proposed Session API will leave this sort
of decision to the container using it, whereas I want WADI to present
the same API to client-containers whether colocation is being enforced
or not... This probably means that I need to think about it a little
harder :-)
I hope that answers your question ?
Jules
>
> -David
>
--
"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.
**********************************/
Re: Summary?
Posted by David Blevins <da...@visi.com>.
On Mar 14, 2006, at 12:55 AM, Jules Gosnell wrote:
> David Blevins wrote:
>
>>
>> On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
>>
>>> David Blevins wrote:
>>>
>>>> Sorry, was referring to this thread. Seems like it's winding
>>>> down and just looking for a clear idea of what the current
>>>> thinking is.
>>>>
>>> David,
>>>
>>> since you are here - a few SFSB questions...
>>>
>>> what provisions does the EJB spec make for timing out of SFSBs,
>>> if any ? what metadata does this require associated with each
>>> session ?
>>
>>
>> What I can recal is that you can't passivate a stateful bean in
>> mid- transaction. You must activate a stateful bean if a client
>> attempts to invoke it and the instance has not yet been timed
>> out. And unlike Entities, Stateful session bean data isn't
>> required to survive a server crash or restart.
>>
>>> what provisions/requirements over and above these does OpenEJB
>>> make/ have ?
>>> Aside from lifecycle management, retrieval and timing out, what
>>> other requirements might OpenEJB have for SFSB management ?
>>
>>
>> Nothing I can think of. Maybe you are looking for something very
>> specific.
>
> I'm wondering how SFSBs are timed out. Does the spec describe this
> or is it container-specific ? Is the time-to-live on a per bean
> instance, type or container-wide basis ? I'm trying to get a
> clearer picture of how we might unify web and ejb session
> lifecycles, so that they can be managed in a single component,
The most specific the spec is on timing out is that "the Deployer
configures" it. It's completely implementation specific and it's
pretty much just required that someone be allowed to set it, whatever
it is and however it may work.
>>> Are Local SFSBs to be considered Serialisable/Passivatable/
>>> Migratable or not ?
>>
>>
>> I think you may be thinking that a client using a Local vs Remote
>> interface to access a stateful bean has a different impact on the
>> stateful bean's lifecycle. The lifecycle is the same regardless
>> of how a client accesses it. In other words, there is no such
>> thing as a local or remote bean, just local or remote reference
>> to beans.
>
> I'm thinking that use of a Local interface relaxes the constraint
> on params being passed through it being Serialisable. This implies
> that the SFSB the other end may be asked to store non-Serialisable
> data. If it does, this would preclude it from being involved in
> operations like passivation and migration....? But, if the activate/
> passivate part of the lifecycle is required of Local SFSBs as well,
> then perhaps this is not an issue ?
Again, wether the stateful bean is accessed via Local vs Remote
interface has zero affect or implications on the bean instance and
it's lifecycle rules. In all cases it's the bean's responsibility
to ensure that it's non-transient fields are serializable or one of
the container-provided objects (datasource refs, UserTransaction,
home objects, local or remote objects, etc).
>>> Would it be simple to change OpenEJB to use an SFSB handle that
>>> included an ID to a 'SuperSession' (Object containing all
>>> Session objects pertaining to a single client for a given
>>> Server) along with an ID to particular 'SubSession' (The SFSB
>>> itself) within this 'SuperSession', instead of whatever scheme
>>> you currently use ?
>>
>>
>> That wouldn't be simple as we don't have any concept of
>> provisioning client ids aside from the optional security identity
>> associated with incoming calls. In general the spec isn't really
>> strict on the server's view of a client, it's more focused on a
>> client's view of a bean (e.g. server). That is to say, beans
>> have strict and spelled out identity rules whereas client's do not.
>>
>> We could invent a universal client id concept but it would be a
>> fair amount of work to reconcile that concept across the various
>> ways people can invoke stateful beans; IIOP+IDL, IIOP+Remote
>> interface, Custom protocol + Remote interface, Local interface.
>> Using just Local interfaces, is the client id:
>> - The id of the servlet or ejb
>> - The id of the war or ejb-jar
>> - The id of the ear (if there is one)
>> - The id of the VM
>>
>> Remote interfaces really get you in trouble as they have the same
>> questions, plus they can be invoked by j2ee app clients as well
>> as non-j2ee java clients, or even non-java clients via IDL/IIOP.
>>
> exactly - there is a can of worms here, which I think we are
> glossing over...
>
> I've been giving some thought to how SFSB keys/ids/handles might
> work in a way that would allow them them to be colocated in a
> SuperSession... It is tricky because of the multiple ways in which
> they might be accessed. I think this needs careful thought and
> discussion. If provisioning of these keys is not easily isolated
> from the rest of OpenEJB then I think we will have problems here...
Provisioning of the actual stateful session bean keys is easy to
isolate, but as I say inventing a client id that you could use as
part of a stateful session bean's id is not easy.
>> I guess I'm not sure at what level you are thinking when you say
>> the word "client" or what you'd be looking to get out of the
>> concept.
>
> anyone addressing one or more SFSBs via the EJB containers services.
I was hoping for something more concrete and not more abstract :)
"Anyone" is way too vague to be useful. As i say, what is most
effective for your purposes? At least a finger in the wind would be
helpful to get my brain around what level you may need. I.e. is a
client a component, or the application the component resides in, or
the VM the application resides in, or the user driving the
application...?
-David
Re: Summary?
Posted by Jules Gosnell <ju...@coredevelopers.net>.
David Blevins wrote:
>
> On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
>
>> David Blevins wrote:
>>
>>> Sorry, was referring to this thread. Seems like it's winding down
>>> and just looking for a clear idea of what the current thinking is.
>>>
>> David,
>>
>> since you are here - a few SFSB questions...
>>
>> what provisions does the EJB spec make for timing out of SFSBs, if
>> any ? what metadata does this require associated with each session ?
>
>
> What I can recal is that you can't passivate a stateful bean in mid-
> transaction. You must activate a stateful bean if a client attempts
> to invoke it and the instance has not yet been timed out. And unlike
> Entities, Stateful session bean data isn't required to survive a
> server crash or restart.
>
>> what provisions/requirements over and above these does OpenEJB make/
>> have ?
>> Aside from lifecycle management, retrieval and timing out, what
>> other requirements might OpenEJB have for SFSB management ?
>
>
> Nothing I can think of. Maybe you are looking for something very
> specific.
I'm wondering how SFSBs are timed out. Does the spec describe this or is
it container-specific ? Is the time-to-live on a per bean instance, type
or container-wide basis ? I'm trying to get a clearer picture of how we
might unify web and ejb session lifecycles, so that they can be managed
in a single component,
>
>> I seem to remember that SFSBs need notification on activation/
>> passivation ? is this correct ? are any other notifications required ?
>
>
> A notification before a passivation (ejbPassivate()/@PrePassivate)
> and another after activation (ejbActivate()/@PostActivate).
>
>> Is it possible for one client to pass the handle of an SFSB to
>> another ? Does the spec touch on this ? Does it ever happen ?
>
>
> I know that per spec, the client identity cannot change mid-
> transaction. Aside from that we allow it.
>
>> Are Local SFSBs to be considered Serialisable/Passivatable/
>> Migratable or not ?
>
>
> I think you may be thinking that a client using a Local vs Remote
> interface to access a stateful bean has a different impact on the
> stateful bean's lifecycle. The lifecycle is the same regardless of
> how a client accesses it. In other words, there is no such thing as
> a local or remote bean, just local or remote reference to beans.
I'm thinking that use of a Local interface relaxes the constraint on
params being passed through it being Serialisable. This implies that the
SFSB the other end may be asked to store non-Serialisable data. If it
does, this would preclude it from being involved in operations like
passivation and migration....? But, if the activate/passivate part of
the lifecycle is required of Local SFSBs as well, then perhaps this is
not an issue ?
>
>> and finally :
>>
>> Would it be simple to change OpenEJB to use an SFSB handle that
>> included an ID to a 'SuperSession' (Object containing all Session
>> objects pertaining to a single client for a given Server) along with
>> an ID to particular 'SubSession' (The SFSB itself) within this
>> 'SuperSession', instead of whatever scheme you currently use ?
>
>
> That wouldn't be simple as we don't have any concept of provisioning
> client ids aside from the optional security identity associated with
> incoming calls. In general the spec isn't really strict on the
> server's view of a client, it's more focused on a client's view of a
> bean (e.g. server). That is to say, beans have strict and spelled
> out identity rules whereas client's do not.
>
> We could invent a universal client id concept but it would be a fair
> amount of work to reconcile that concept across the various ways
> people can invoke stateful beans; IIOP+IDL, IIOP+Remote interface,
> Custom protocol + Remote interface, Local interface. Using just
> Local interfaces, is the client id:
> - The id of the servlet or ejb
> - The id of the war or ejb-jar
> - The id of the ear (if there is one)
> - The id of the VM
>
> Remote interfaces really get you in trouble as they have the same
> questions, plus they can be invoked by j2ee app clients as well as
> non-j2ee java clients, or even non-java clients via IDL/IIOP.
>
exactly - there is a can of worms here, which I think we are glossing
over...
I've been giving some thought to how SFSB keys/ids/handles might work in
a way that would allow them them to be colocated in a SuperSession... It
is tricky because of the multiple ways in which they might be accessed.
I think this needs careful thought and discussion. If provisioning of
these keys is not easily isolated from the rest of OpenEJB then I think
we will have problems here...
> I guess I'm not sure at what level you are thinking when you say the
> word "client" or what you'd be looking to get out of the concept.
anyone addressing one or more SFSBs via the EJB containers services.
> That'd probably be the most productive way to look at the concept
> -- otherwise it becomes one of those existentialist "what is a
> component" type of things.
>
>> looking forward to some interesting answers...
>
>
> Hope they help!
of course ! Thanks.
Jules
>
> -David
>
>
>>
>>
>> Jules
>>
>>>
>>> -David
>>>
>>> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>>>
>>>> Looks good.
>>>>
>>>> -dain
>>>>
>>>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>>>
>>>>> Dain Sundstrom wrote:
>>>>>
>>>>>> My guess is we're going to need to add an event notification
>>>>>> system to
>>>>>> the Session APIs. What do you think about just crib off of
>>>>>> the servlet
>>>>>> ones. I think we could just smash the three session listener
>>>>>> interfaces into something like this:
>>>>>>
>>>>>> public interface SessionListener extends Listener {
>>>>>> void valueBound(SessionEvent event);
>>>>>> void valueUnbound(SessionEvent event);
>>>>>> void attributeAdded(SessionEvent event);
>>>>>> void attributeRemoved(SessionEvent event);
>>>>>> void attributeRemoved(SessionEvent event);
>>>>>
>>>>>
>>>>>
>>>>> I think you mean:
>>>>> void attributeReplaced(SessionEvent event);
>>>>>
>>>>>
>>>>>> void valueBound(SessionEvent event);
>>>>>> void valueUnbound(SessionEvent event);
>>>>>> void sessionCreated(SessionEvent event)
>>>>>> void sessionDestroyed(SessionEvent event)
>>>>>> }
>>>>>>
>>>>>> public class SessionEvent extends Event {
>>>>>> Session getSession();
>>>>>> String getName();
>>>>>> String getValue();
>>>>>> }
>>>>>>
>>>>>> We would bind a listener with a method on the Locator:
>>>>>>
>>>>>> void addSessionListener(SessionListener listener);
>>>>>> void removeSessionListener(SessionListener listener);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> that would certainly do it - the only change I'd like to see
>>>>> is that the SessionEvent is
>>>>>
>>>>>
>>>>> public class SessionEvent extends Event {
>>>>> Session getSession();
>>>>> String getName();
>>>>> String getOldValue();
>>>>> String getNewValue();
>>>>> }
>>>>>
>>>>> As it is confusing for remove and replace what getValue() returns.
>>>>>
>>>>> Also as the bound/unbound events are actually called on the
>>>>> value itself, you need both old and new values so you can call
>>>>> unbind and bind during a replace.
>>>>>
>>>>> cheers
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> "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.
>> **********************************/
>>
>
--
"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.
**********************************/
Re: Summary?
Posted by David Blevins <da...@visi.com>.
On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
> David Blevins wrote:
>
>> Sorry, was referring to this thread. Seems like it's winding
>> down and just looking for a clear idea of what the current
>> thinking is.
>>
> David,
>
> since you are here - a few SFSB questions...
>
> what provisions does the EJB spec make for timing out of SFSBs, if
> any ? what metadata does this require associated with each session ?
What I can recal is that you can't passivate a stateful bean in mid-
transaction. You must activate a stateful bean if a client attempts
to invoke it and the instance has not yet been timed out. And unlike
Entities, Stateful session bean data isn't required to survive a
server crash or restart.
> what provisions/requirements over and above these does OpenEJB make/
> have ?
> Aside from lifecycle management, retrieval and timing out, what
> other requirements might OpenEJB have for SFSB management ?
Nothing I can think of. Maybe you are looking for something very
specific.
> I seem to remember that SFSBs need notification on activation/
> passivation ? is this correct ? are any other notifications required ?
A notification before a passivation (ejbPassivate()/@PrePassivate)
and another after activation (ejbActivate()/@PostActivate).
> Is it possible for one client to pass the handle of an SFSB to
> another ? Does the spec touch on this ? Does it ever happen ?
I know that per spec, the client identity cannot change mid-
transaction. Aside from that we allow it.
> Are Local SFSBs to be considered Serialisable/Passivatable/
> Migratable or not ?
I think you may be thinking that a client using a Local vs Remote
interface to access a stateful bean has a different impact on the
stateful bean's lifecycle. The lifecycle is the same regardless of
how a client accesses it. In other words, there is no such thing as
a local or remote bean, just local or remote reference to beans.
> and finally :
>
> Would it be simple to change OpenEJB to use an SFSB handle that
> included an ID to a 'SuperSession' (Object containing all Session
> objects pertaining to a single client for a given Server) along
> with an ID to particular 'SubSession' (The SFSB itself) within this
> 'SuperSession', instead of whatever scheme you currently use ?
That wouldn't be simple as we don't have any concept of provisioning
client ids aside from the optional security identity associated with
incoming calls. In general the spec isn't really strict on the
server's view of a client, it's more focused on a client's view of a
bean (e.g. server). That is to say, beans have strict and spelled
out identity rules whereas client's do not.
We could invent a universal client id concept but it would be a fair
amount of work to reconcile that concept across the various ways
people can invoke stateful beans; IIOP+IDL, IIOP+Remote interface,
Custom protocol + Remote interface, Local interface. Using just
Local interfaces, is the client id:
- The id of the servlet or ejb
- The id of the war or ejb-jar
- The id of the ear (if there is one)
- The id of the VM
Remote interfaces really get you in trouble as they have the same
questions, plus they can be invoked by j2ee app clients as well as
non-j2ee java clients, or even non-java clients via IDL/IIOP.
I guess I'm not sure at what level you are thinking when you say the
word "client" or what you'd be looking to get out of the concept.
That'd probably be the most productive way to look at the concept --
otherwise it becomes one of those existentialist "what is a
component" type of things.
> looking forward to some interesting answers...
Hope they help!
-David
>
>
> Jules
>
>>
>> -David
>>
>> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>>
>>> Looks good.
>>>
>>> -dain
>>>
>>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>>
>>>> Dain Sundstrom wrote:
>>>>
>>>>> My guess is we're going to need to add an event notification
>>>>> system to
>>>>> the Session APIs. What do you think about just crib off of
>>>>> the servlet
>>>>> ones. I think we could just smash the three session listener
>>>>> interfaces into something like this:
>>>>>
>>>>> public interface SessionListener extends Listener {
>>>>> void valueBound(SessionEvent event);
>>>>> void valueUnbound(SessionEvent event);
>>>>> void attributeAdded(SessionEvent event);
>>>>> void attributeRemoved(SessionEvent event);
>>>>> void attributeRemoved(SessionEvent event);
>>>>
>>>>
>>>> I think you mean:
>>>> void attributeReplaced(SessionEvent event);
>>>>
>>>>
>>>>> void valueBound(SessionEvent event);
>>>>> void valueUnbound(SessionEvent event);
>>>>> void sessionCreated(SessionEvent event)
>>>>> void sessionDestroyed(SessionEvent event)
>>>>> }
>>>>>
>>>>> public class SessionEvent extends Event {
>>>>> Session getSession();
>>>>> String getName();
>>>>> String getValue();
>>>>> }
>>>>>
>>>>> We would bind a listener with a method on the Locator:
>>>>>
>>>>> void addSessionListener(SessionListener listener);
>>>>> void removeSessionListener(SessionListener listener);
>>>>
>>>>
>>>>
>>>>
>>>> that would certainly do it - the only change I'd like to see
>>>> is that the SessionEvent is
>>>>
>>>>
>>>> public class SessionEvent extends Event {
>>>> Session getSession();
>>>> String getName();
>>>> String getOldValue();
>>>> String getNewValue();
>>>> }
>>>>
>>>> As it is confusing for remove and replace what getValue() returns.
>>>>
>>>> Also as the bound/unbound events are actually called on the
>>>> value itself, you need both old and new values so you can call
>>>> unbind and bind during a replace.
>>>>
>>>> cheers
>>>
>>>
>>
>
>
> --
> "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.
> **********************************/
>
Re: Summary?
Posted by Jules Gosnell <ju...@coredevelopers.net>.
David Blevins wrote:
> Sorry, was referring to this thread. Seems like it's winding down
> and just looking for a clear idea of what the current thinking is.
>
David,
since you are here - a few SFSB questions...
what provisions does the EJB spec make for timing out of SFSBs, if any ?
what metadata does this require associated with each session ?
what provisions/requirements over and above these does OpenEJB make/have ?
I seem to remember that SFSBs need notification on
activation/passivation ? is this correct ? are any other notifications
required ?
Is it possible for one client to pass the handle of an SFSB to another ?
Does the spec touch on this ? Does it ever happen ?
Aside from lifecycle management, retrieval and timing out, what other
requirements might OpenEJB have for SFSB management ?
Are Local SFSBs to be considered Serialisable/Passivatable/Migratable or
not ?
and finally :
Would it be simple to change OpenEJB to use an SFSB handle that included
an ID to a 'SuperSession' (Object containing all Session objects
pertaining to a single client for a given Server) along with an ID to
particular 'SubSession' (The SFSB itself) within this 'SuperSession',
instead of whatever scheme you currently use ?
looking forward to some interesting answers...
Jules
>
> -David
>
> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>
>> Looks good.
>>
>> -dain
>>
>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>
>>> Dain Sundstrom wrote:
>>>
>>>> My guess is we're going to need to add an event notification
>>>> system to
>>>> the Session APIs. What do you think about just crib off of the
>>>> servlet
>>>> ones. I think we could just smash the three session listener
>>>> interfaces into something like this:
>>>>
>>>> public interface SessionListener extends Listener {
>>>> void valueBound(SessionEvent event);
>>>> void valueUnbound(SessionEvent event);
>>>> void attributeAdded(SessionEvent event);
>>>> void attributeRemoved(SessionEvent event);
>>>> void attributeRemoved(SessionEvent event);
>>>
>>>
>>> I think you mean:
>>> void attributeReplaced(SessionEvent event);
>>>
>>>
>>>> void valueBound(SessionEvent event);
>>>> void valueUnbound(SessionEvent event);
>>>> void sessionCreated(SessionEvent event)
>>>> void sessionDestroyed(SessionEvent event)
>>>> }
>>>>
>>>> public class SessionEvent extends Event {
>>>> Session getSession();
>>>> String getName();
>>>> String getValue();
>>>> }
>>>>
>>>> We would bind a listener with a method on the Locator:
>>>>
>>>> void addSessionListener(SessionListener listener);
>>>> void removeSessionListener(SessionListener listener);
>>>
>>>
>>>
>>>
>>> that would certainly do it - the only change I'd like to see
>>> is that the SessionEvent is
>>>
>>>
>>> public class SessionEvent extends Event {
>>> Session getSession();
>>> String getName();
>>> String getOldValue();
>>> String getNewValue();
>>> }
>>>
>>> As it is confusing for remove and replace what getValue() returns.
>>>
>>> Also as the bound/unbound events are actually called on the
>>> value itself, you need both old and new values so you can call
>>> unbind and bind during a replace.
>>>
>>> cheers
>>
>>
>
--
"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.
**********************************/
Re: Summary? was: Session API....
Posted by Jeff Genender <jg...@apache.org>.
+1 from me...looks like the right track.
Dain Sundstrom wrote:
> Sorry I've been a bit checked out lately... working on 1.1.
>
> I think we all agree in the APIs for sessions themselves (i.e.,
> everything but location), and we agree that we need an event interface
> like this:
>
> void addSessionListener(SessionListener listener);
> void removeSessionListener(SessionListener listener);
>
> public interface SessionListener extends Listener {
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void attributeAdded(SessionEvent event);
> void attributeRemoved(SessionEvent event);
> void attributeReplaced(SessionEvent event);
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void sessionCreated(SessionEvent event)
> void sessionDestroyed(SessionEvent event)
> }
>
> public class SessionEvent extends Event {
> Session getSession();
> String getName();
> String getOldValue();
> String getNewValue();
> }
>
> We still disagree on how exactly you obtain the session object for a
> given session id. I think the most important part of this disagreement
> to solve first, is should we have an API to make the redirect/proxy/move
> decision on a generic invocation object, or should we have the session
> API know the location of the session (this is what is does now, but this
> is not necessarily the final API).
>
> Does everyone agree with this summary? If so, I suggest we add the
> agreed upon event interface above and continue our discussion about last
> contentious point.
>
> -dain
Re: Summary? was: Session API....
Posted by Dain Sundstrom <da...@iq80.com>.
Sorry I've been a bit checked out lately... working on 1.1.
I think we all agree in the APIs for sessions themselves (i.e.,
everything but location), and we agree that we need an event
interface like this:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeReplaced(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getOldValue();
String getNewValue();
}
We still disagree on how exactly you obtain the session object for a
given session id. I think the most important part of this
disagreement to solve first, is should we have an API to make the
redirect/proxy/move decision on a generic invocation object, or
should we have the session API know the location of the session (this
is what is does now, but this is not necessarily the final API).
Does everyone agree with this summary? If so, I suggest we add the
agreed upon event interface above and continue our discussion about
last contentious point.
-dain
Re: Summary? was: Session API....
Posted by David Blevins <da...@visi.com>.
On Mar 11, 2006, at 2:33 PM, Jules Gosnell wrote:
> David,
>
> If you can have a go at answering the questions I have posed about
> [Open]EJB in my other posting on this thread, I will merge your
> answers into the model I am carrying around in my head and dump it
> into an email as soon as I can. Then we can investigate and discuss
> the differences between WADI's approach to these problems and the
> proposed Session API.
Ok, answered those questions. Here are my first-blush thoughts/
questions again on the summary you posted.
>> I like the concept that clients can be made smarter or store
>> information that will make the cluster that much more efficient.
>> But I'm not sure what you'd need me to do for clients that are
>> out of our control and potentially written in an entirely
>> different language, i.e. CORBA and Web Services.
>>
>> Can you describe what considerations I'd have to add on my side
>> of the fence to make that work?
Thanks,
David
Re: Summary? was: Session API....
Posted by Jules Gosnell <ju...@coredevelopers.net>.
David Blevins wrote:
> On Mar 9, 2006, at 4:09 AM, Jules Gosnell wrote:
>
>> David Blevins wrote:
>>
>>> Sorry, was referring to this thread. Seems like it's winding down
>>> and just looking for a clear idea of what the current thinking is.
>>
>>
>> Hi David - allow me to wind it up again :-)
>>
>> I am particularly interested in your thoughts/requirements about a
>> Session management API for OpenEJB... You seemed to have remained a
>> little quiet on this thread...
>
>
> It's a tough topic to digest in the form of lots of little emails. I
> really appreciate the time you put into this summary.
>
> I think I'm getting a lot of what you are saying. I have to admit, I
> still can't imagine it all in my head just yet. I like the concept
> that clients can be made smarter or store information that will make
> the cluster that much more efficient. But I'm not sure what you'd
> need me to do for clients that are out of our control and potentially
> written in an entirely different language, i.e. CORBA and Web Services.
>
> Can you describe what considerations I'd have to add on my side of
> the fence to make that work?
David,
If you can have a go at answering the questions I have posed about
[Open]EJB in my other posting on this thread, I will merge your answers
into the model I am carrying around in my head and dump it into an email
as soon as I can. Then we can investigate and discuss the differences
between WADI's approach to these problems and the proposed Session API.
Looking forward to it,
Jules
>
> -David
>
>
>>
>> Here we go:
>>
>>
>> Guys,
>>
>> Firstly, I think a unified Session API is a good thing - it's
>> something that I have been working towards in WADI for sometime.
>>
>> Secondly, I have many issues with this one :-)
>>
>> It may be that I have misunderstood aspects of this API and I am open
>> to correction where this has happened.
>>
>> All observations are off the top of my head - since I until I actually
>> try to put WADI behind this API, I am not going to discover the full
>> breadth of my problems.
>>
>> To keep things as simple as possible, I am only going to go for the
>> big money... I'll make 3 points, then illustrate them.
>>
>> 1)
>>
>> I would like to see a very clear distinction between what I call the
>> 'Session API' (The API used between the container -
>> Jetty/Tomcat/OpenEJB etc - and Geronimo, for Session creation,
>> destruction and retrieval), what Greg is calling the 'Policy' SPI
>> (The stuff that worries about things like the location of a Session
>> and whether it is Local or Remote) and what I guess is your current
>> 'Policy' implementation.
>>
>> I see the successful definition of the 'Session API' component as the
>> most important of these. The 'Policy SPI' is going to be more
>> contentious - your current API and implementation seem quite closely
>> bound and present a number of issues for WADI.
>>
>> 2)
>>
>> I think that the issue of session colocation should not be exposed in
>> the 'Session API' component. I see this very much as a pluggable
>> implementation detail, that is irrelevant to the container using the
>> API. The implementation behind the API will be in full control of
>> creation of the Key, the Session, the Session lifecycle and Session
>> storage. I do not see why you need to expose any detail of your
>> internal mechanisms to the Session consumer.
>>
>> 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.
>>
>> 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)
>> 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
>> should pass the necessary information to the Session management impl
>> so that it can take a decision about how it wishes to represent this
>> Session. This choice of representation is very implementation specific
>> and will have consequences for the granularity at which Sessions and
>> their Attributes may be replicated, serialised, enumerated and
>> iterated upon. By exposing an API we must necessarily provide one. Any
>> one that we provide will be biased towards a particular impl. I think
>> it is better to avoid this entirely by keeping this in the
>> implementation.
>>
>> 3)
>>
>> (a) The API needs to make provision for the interception of this
>> Invocation and its passing to the Session management layer for
>> consideration. This is the point at which the implementation may need
>> to make the decision whether to relocate the Invocation to the
>> Session or the Session to the Invocation - what Greg, I think, calls
>> the 'Policy'
>>
>> (b) e.g. WADI uses access to the Invocation to, amongst other things,
>> rewrite the value of Http Session Cookies to tell Apache/ModJK about
>> the Location of a Session, so that ModJK can route subsequent
>> requests to the correct node. I think with the arrival of more
>> intelligent load-balancer integrations, intelligent client-side
>> stubs, session types and tiers that we need to ensure that the
>> Invocation is encapsulated and made available to the Session
>> management layer at every opportunity, so that sophisticated
>> integration may be developed between Client and Session manager.
>>
>> That's enough for now :-)
>>
>>
>> Jules
>>
>>
>>
>>>
>>>
>>> -David
>>>
>>> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>>>
>>>> Looks good.
>>>>
>>>> -dain
>>>>
>>>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>>>
>>>>> Dain Sundstrom wrote:
>>>>>
>>>>>> My guess is we're going to need to add an event notification
>>>>>> system to
>>>>>> the Session APIs. What do you think about just crib off of
>>>>>> the servlet
>>>>>> ones. I think we could just smash the three session listener
>>>>>> interfaces into something like this:
>>>>>>
>>>>>> public interface SessionListener extends Listener {
>>>>>> void valueBound(SessionEvent event);
>>>>>> void valueUnbound(SessionEvent event);
>>>>>> void attributeAdded(SessionEvent event);
>>>>>> void attributeRemoved(SessionEvent event);
>>>>>> void attributeRemoved(SessionEvent event);
>>>>>
>>>>>
>>>>>
>>>>> I think you mean:
>>>>> void attributeReplaced(SessionEvent event);
>>>>>
>>>>>
>>>>>> void valueBound(SessionEvent event);
>>>>>> void valueUnbound(SessionEvent event);
>>>>>> void sessionCreated(SessionEvent event)
>>>>>> void sessionDestroyed(SessionEvent event)
>>>>>> }
>>>>>>
>>>>>> public class SessionEvent extends Event {
>>>>>> Session getSession();
>>>>>> String getName();
>>>>>> String getValue();
>>>>>> }
>>>>>>
>>>>>> We would bind a listener with a method on the Locator:
>>>>>>
>>>>>> void addSessionListener(SessionListener listener);
>>>>>> void removeSessionListener(SessionListener listener);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> that would certainly do it - the only change I'd like to see
>>>>> is that the SessionEvent is
>>>>>
>>>>>
>>>>> public class SessionEvent extends Event {
>>>>> Session getSession();
>>>>> String getName();
>>>>> String getOldValue();
>>>>> String getNewValue();
>>>>> }
>>>>>
>>>>> As it is confusing for remove and replace what getValue() returns.
>>>>>
>>>>> Also as the bound/unbound events are actually called on the
>>>>> value itself, you need both old and new values so you can call
>>>>> unbind and bind during a replace.
>>>>>
>>>>> cheers
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> "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.
>> **********************************/
>>
>
--
"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.
**********************************/
Re: Summary? was: Session API....
Posted by David Blevins <da...@visi.com>.
On Mar 9, 2006, at 4:09 AM, Jules Gosnell wrote:
> David Blevins wrote:
>
>> Sorry, was referring to this thread. Seems like it's winding
>> down and just looking for a clear idea of what the current
>> thinking is.
>
> Hi David - allow me to wind it up again :-)
>
> I am particularly interested in your thoughts/requirements about a
> Session management API for OpenEJB... You seemed to have remained a
> little quiet on this thread...
It's a tough topic to digest in the form of lots of little emails. I
really appreciate the time you put into this summary.
I think I'm getting a lot of what you are saying. I have to admit, I
still can't imagine it all in my head just yet. I like the concept
that clients can be made smarter or store information that will make
the cluster that much more efficient. But I'm not sure what you'd
need me to do for clients that are out of our control and potentially
written in an entirely different language, i.e. CORBA and Web Services.
Can you describe what considerations I'd have to add on my side of
the fence to make that work?
-David
>
> Here we go:
>
>
> Guys,
>
> Firstly, I think a unified Session API is a good thing - it's
> something that I have been working towards in WADI for sometime.
>
> Secondly, I have many issues with this one :-)
>
> It may be that I have misunderstood aspects of this API and I am open
> to correction where this has happened.
>
> All observations are off the top of my head - since I until I actually
> try to put WADI behind this API, I am not going to discover the full
> breadth of my problems.
>
> To keep things as simple as possible, I am only going to go for the
> big money... I'll make 3 points, then illustrate them.
>
> 1)
>
> I would like to see a very clear distinction between what I call the
> 'Session API' (The API used between the container -
> Jetty/Tomcat/OpenEJB etc - and Geronimo, for Session creation,
> destruction and retrieval), what Greg is calling the 'Policy' SPI
> (The stuff that worries about things like the location of a Session
> and whether it is Local or Remote) and what I guess is your current
> 'Policy' implementation.
>
> I see the successful definition of the 'Session API' component as the
> most important of these. The 'Policy SPI' is going to be more
> contentious - your current API and implementation seem quite closely
> bound and present a number of issues for WADI.
>
> 2)
>
> I think that the issue of session colocation should not be exposed in
> the 'Session API' component. I see this very much as a pluggable
> implementation detail, that is irrelevant to the container using the
> API. The implementation behind the API will be in full control of
> creation of the Key, the Session, the Session lifecycle and Session
> storage. I do not see why you need to expose any detail of your
> internal mechanisms to the Session consumer.
>
> 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.
>
> 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)
> 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
> should pass the necessary information to the Session management impl
> so that it can take a decision about how it wishes to represent this
> Session. This choice of representation is very implementation specific
> and will have consequences for the granularity at which Sessions and
> their Attributes may be replicated, serialised, enumerated and
> iterated upon. By exposing an API we must necessarily provide one. Any
> one that we provide will be biased towards a particular impl. I think
> it is better to avoid this entirely by keeping this in the
> implementation.
>
> 3)
>
> (a) The API needs to make provision for the interception of this
> Invocation and its passing to the Session management layer for
> consideration. This is the point at which the implementation may need
> to make the decision whether to relocate the Invocation to the
> Session or the Session to the Invocation - what Greg, I think, calls
> the 'Policy'
>
> (b) e.g. WADI uses access to the Invocation to, amongst other things,
> rewrite the value of Http Session Cookies to tell Apache/ModJK about
> the Location of a Session, so that ModJK can route subsequent
> requests to the correct node. I think with the arrival of more
> intelligent load-balancer integrations, intelligent client-side
> stubs, session types and tiers that we need to ensure that the
> Invocation is encapsulated and made available to the Session
> management layer at every opportunity, so that sophisticated
> integration may be developed between Client and Session manager.
>
> That's enough for now :-)
>
>
> Jules
>
>
>
>>
>>
>> -David
>>
>> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>>
>>> Looks good.
>>>
>>> -dain
>>>
>>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>>
>>>> Dain Sundstrom wrote:
>>>>
>>>>> My guess is we're going to need to add an event notification
>>>>> system to
>>>>> the Session APIs. What do you think about just crib off of
>>>>> the servlet
>>>>> ones. I think we could just smash the three session listener
>>>>> interfaces into something like this:
>>>>>
>>>>> public interface SessionListener extends Listener {
>>>>> void valueBound(SessionEvent event);
>>>>> void valueUnbound(SessionEvent event);
>>>>> void attributeAdded(SessionEvent event);
>>>>> void attributeRemoved(SessionEvent event);
>>>>> void attributeRemoved(SessionEvent event);
>>>>
>>>>
>>>> I think you mean:
>>>> void attributeReplaced(SessionEvent event);
>>>>
>>>>
>>>>> void valueBound(SessionEvent event);
>>>>> void valueUnbound(SessionEvent event);
>>>>> void sessionCreated(SessionEvent event)
>>>>> void sessionDestroyed(SessionEvent event)
>>>>> }
>>>>>
>>>>> public class SessionEvent extends Event {
>>>>> Session getSession();
>>>>> String getName();
>>>>> String getValue();
>>>>> }
>>>>>
>>>>> We would bind a listener with a method on the Locator:
>>>>>
>>>>> void addSessionListener(SessionListener listener);
>>>>> void removeSessionListener(SessionListener listener);
>>>>
>>>>
>>>>
>>>>
>>>> that would certainly do it - the only change I'd like to see
>>>> is that the SessionEvent is
>>>>
>>>>
>>>> public class SessionEvent extends Event {
>>>> Session getSession();
>>>> String getName();
>>>> String getOldValue();
>>>> String getNewValue();
>>>> }
>>>>
>>>> As it is confusing for remove and replace what getValue() returns.
>>>>
>>>> Also as the bound/unbound events are actually called on the
>>>> value itself, you need both old and new values so you can call
>>>> unbind and bind during a replace.
>>>>
>>>> cheers
>>>
>>>
>>
>
>
> --
> "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.
> **********************************/
>
Re: Summary? was: Session API....
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Hi Hiram :-)
Hiram Chirino wrote:
>
>
> On 3/9/06, *Jules Gosnell* <jules@coredevelopers.net
> <ma...@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
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
outcome.
>
>
> 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
SessionManager.
>
> --
> 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"
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.
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.
**********************************/
Re: Summary? was: Session API....
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 3/9/06, Jules Gosnell <ju...@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"
Re: Summary? was: Session API....
Posted by Jules Gosnell <ju...@coredevelopers.net>.
David Blevins wrote:
> Sorry, was referring to this thread. Seems like it's winding down
> and just looking for a clear idea of what the current thinking is.
Hi David - allow me to wind it up again :-)
I am particularly interested in your thoughts/requirements about a
Session management API for OpenEJB... You seemed to have remained a
little quiet on this thread...
Here we go:
Guys,
Firstly, I think a unified Session API is a good thing - it's
something that I have been working towards in WADI for sometime.
Secondly, I have many issues with this one :-)
It may be that I have misunderstood aspects of this API and I am open
to correction where this has happened.
All observations are off the top of my head - since I until I actually
try to put WADI behind this API, I am not going to discover the full
breadth of my problems.
To keep things as simple as possible, I am only going to go for the
big money... I'll make 3 points, then illustrate them.
1)
I would like to see a very clear distinction between what I call the
'Session API' (The API used between the container -
Jetty/Tomcat/OpenEJB etc - and Geronimo, for Session creation,
destruction and retrieval), what Greg is calling the 'Policy' SPI
(The stuff that worries about things like the location of a Session
and whether it is Local or Remote) and what I guess is your current
'Policy' implementation.
I see the successful definition of the 'Session API' component as the
most important of these. The 'Policy SPI' is going to be more
contentious - your current API and implementation seem quite closely
bound and present a number of issues for WADI.
2)
I think that the issue of session colocation should not be exposed in
the 'Session API' component. I see this very much as a pluggable
implementation detail, that is irrelevant to the container using the
API. The implementation behind the API will be in full control of
creation of the Key, the Session, the Session lifecycle and Session
storage. I do not see why you need to expose any detail of your
internal mechanisms to the Session consumer.
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.
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)
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
should pass the necessary information to the Session management impl
so that it can take a decision about how it wishes to represent this
Session. This choice of representation is very implementation specific
and will have consequences for the granularity at which Sessions and
their Attributes may be replicated, serialised, enumerated and
iterated upon. By exposing an API we must necessarily provide one. Any
one that we provide will be biased towards a particular impl. I think
it is better to avoid this entirely by keeping this in the
implementation.
3)
(a) The API needs to make provision for the interception of this
Invocation and its passing to the Session management layer for
consideration. This is the point at which the implementation may need
to make the decision whether to relocate the Invocation to the
Session or the Session to the Invocation - what Greg, I think, calls
the 'Policy'
(b) e.g. WADI uses access to the Invocation to, amongst other things,
rewrite the value of Http Session Cookies to tell Apache/ModJK about
the Location of a Session, so that ModJK can route subsequent
requests to the correct node. I think with the arrival of more
intelligent load-balancer integrations, intelligent client-side
stubs, session types and tiers that we need to ensure that the
Invocation is encapsulated and made available to the Session
management layer at every opportunity, so that sophisticated
integration may be developed between Client and Session manager.
That's enough for now :-)
Jules
>
>
> -David
>
> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>
>> Looks good.
>>
>> -dain
>>
>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>
>>> Dain Sundstrom wrote:
>>>
>>>> My guess is we're going to need to add an event notification
>>>> system to
>>>> the Session APIs. What do you think about just crib off of the
>>>> servlet
>>>> ones. I think we could just smash the three session listener
>>>> interfaces into something like this:
>>>>
>>>> public interface SessionListener extends Listener {
>>>> void valueBound(SessionEvent event);
>>>> void valueUnbound(SessionEvent event);
>>>> void attributeAdded(SessionEvent event);
>>>> void attributeRemoved(SessionEvent event);
>>>> void attributeRemoved(SessionEvent event);
>>>
>>>
>>> I think you mean:
>>> void attributeReplaced(SessionEvent event);
>>>
>>>
>>>> void valueBound(SessionEvent event);
>>>> void valueUnbound(SessionEvent event);
>>>> void sessionCreated(SessionEvent event)
>>>> void sessionDestroyed(SessionEvent event)
>>>> }
>>>>
>>>> public class SessionEvent extends Event {
>>>> Session getSession();
>>>> String getName();
>>>> String getValue();
>>>> }
>>>>
>>>> We would bind a listener with a method on the Locator:
>>>>
>>>> void addSessionListener(SessionListener listener);
>>>> void removeSessionListener(SessionListener listener);
>>>
>>>
>>>
>>>
>>> that would certainly do it - the only change I'd like to see
>>> is that the SessionEvent is
>>>
>>>
>>> public class SessionEvent extends Event {
>>> Session getSession();
>>> String getName();
>>> String getOldValue();
>>> String getNewValue();
>>> }
>>>
>>> As it is confusing for remove and replace what getValue() returns.
>>>
>>> Also as the bound/unbound events are actually called on the
>>> value itself, you need both old and new values so you can call
>>> unbind and bind during a replace.
>>>
>>> cheers
>>
>>
>
--
"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.
**********************************/
Summary? (was: Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany)
Posted by David Blevins <da...@visi.com>.
Sorry, was referring to this thread. Seems like it's winding down
and just looking for a clear idea of what the current thinking is.
-David
On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
> Looks good.
>
> -dain
>
> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>
>> Dain Sundstrom wrote:
>>
>>> My guess is we're going to need to add an event notification
>>> system to
>>> the Session APIs. What do you think about just crib off of the
>>> servlet
>>> ones. I think we could just smash the three session listener
>>> interfaces into something like this:
>>>
>>> public interface SessionListener extends Listener {
>>> void valueBound(SessionEvent event);
>>> void valueUnbound(SessionEvent event);
>>> void attributeAdded(SessionEvent event);
>>> void attributeRemoved(SessionEvent event);
>>> void attributeRemoved(SessionEvent event);
>>
>> I think you mean:
>> void attributeReplaced(SessionEvent event);
>>
>>
>>> void valueBound(SessionEvent event);
>>> void valueUnbound(SessionEvent event);
>>> void sessionCreated(SessionEvent event)
>>> void sessionDestroyed(SessionEvent event)
>>> }
>>>
>>> public class SessionEvent extends Event {
>>> Session getSession();
>>> String getName();
>>> String getValue();
>>> }
>>>
>>> We would bind a listener with a method on the Locator:
>>>
>>> void addSessionListener(SessionListener listener);
>>> void removeSessionListener(SessionListener listener);
>>
>>
>>
>> that would certainly do it - the only change I'd like to see
>> is that the SessionEvent is
>>
>>
>> public class SessionEvent extends Event {
>> Session getSession();
>> String getName();
>> String getOldValue();
>> String getNewValue();
>> }
>>
>> As it is confusing for remove and replace what getValue() returns.
>>
>> Also as the bound/unbound events are actually called on the
>> value itself, you need both old and new values so you can call
>> unbind and bind during a replace.
>>
>> cheers
>
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
Looks good.
-dain
On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>
>> My guess is we're going to need to add an event notification
>> system to
>> the Session APIs. What do you think about just crib off of the
>> servlet
>> ones. I think we could just smash the three session listener
>> interfaces into something like this:
>>
>> public interface SessionListener extends Listener {
>> void valueBound(SessionEvent event);
>> void valueUnbound(SessionEvent event);
>> void attributeAdded(SessionEvent event);
>> void attributeRemoved(SessionEvent event);
>> void attributeRemoved(SessionEvent event);
>
> I think you mean:
> void attributeReplaced(SessionEvent event);
>
>
>> void valueBound(SessionEvent event);
>> void valueUnbound(SessionEvent event);
>> void sessionCreated(SessionEvent event)
>> void sessionDestroyed(SessionEvent event)
>> }
>>
>> public class SessionEvent extends Event {
>> Session getSession();
>> String getName();
>> String getValue();
>> }
>>
>> We would bind a listener with a method on the Locator:
>>
>> void addSessionListener(SessionListener listener);
>> void removeSessionListener(SessionListener listener);
>
>
>
> that would certainly do it - the only change I'd like to see
> is that the SessionEvent is
>
>
> public class SessionEvent extends Event {
> Session getSession();
> String getName();
> String getOldValue();
> String getNewValue();
> }
>
> As it is confusing for remove and replace what getValue() returns.
>
> Also as the bound/unbound events are actually called on the
> value itself, you need both old and new values so you can call
> unbind and bind during a replace.
>
> cheers
Re: Session API, was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> My guess is we're going to need to add an event notification system to
> the Session APIs. What do you think about just crib off of the servlet
> ones. I think we could just smash the three session listener
> interfaces into something like this:
>
> public interface SessionListener extends Listener {
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void attributeAdded(SessionEvent event);
> void attributeRemoved(SessionEvent event);
> void attributeRemoved(SessionEvent event);
I think you mean:
void attributeReplaced(SessionEvent event);
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void sessionCreated(SessionEvent event)
> void sessionDestroyed(SessionEvent event)
> }
>
> public class SessionEvent extends Event {
> Session getSession();
> String getName();
> String getValue();
> }
>
> We would bind a listener with a method on the Locator:
>
> void addSessionListener(SessionListener listener);
> void removeSessionListener(SessionListener listener);
that would certainly do it - the only change I'd like to see
is that the SessionEvent is
public class SessionEvent extends Event {
Session getSession();
String getName();
String getOldValue();
String getNewValue();
}
As it is confusing for remove and replace what getValue() returns.
Also as the bound/unbound events are actually called on the
value itself, you need both old and new values so you can call
unbind and bind during a replace.
cheers
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by James Strachan <ja...@gmail.com>.
On 3 Mar 2006, at 18:00, Dain Sundstrom wrote:
> On Mar 3, 2006, at 6:41 AM, Greg Wilkins wrote:
>> Dain Sundstrom wrote:
>> I still don't know if this approach can help with event notification,
>> but I defer that until I have a quasi-working session manager against
>> the API.
>
> My guess is we're going to need to add an event notification system
> to the Session APIs. What do you think about just crib off of the
> servlet ones. I think we could just smash the three session
> listener interfaces into something like this:
>
> public interface SessionListener extends Listener {
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void attributeAdded(SessionEvent event);
> void attributeRemoved(SessionEvent event);
> void attributeRemoved(SessionEvent event);
> void valueBound(SessionEvent event);
> void valueUnbound(SessionEvent event);
> void sessionCreated(SessionEvent event)
> void sessionDestroyed(SessionEvent event)
> }
>
> public class SessionEvent extends Event {
> Session getSession();
> String getName();
> String getValue();
> }
>
> We would bind a listener with a method on the Locator:
>
> void addSessionListener(SessionListener listener);
> void removeSessionListener(SessionListener listener);
>
>
> What do you think?
Looks good. We can refactor later as needed
James
-------
http://radio.weblogs.com/0112098/
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 3, 2006, at 6:41 AM, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>> Object value = session.getState("web:/context-" + name);
>
> Ok I get it now.
>
> Don't have a deep - hard to replicate - structure.
> Have a flat structure, but with a scoped name space!
>
> I think this approach solves a lot of issues and probably
> reduces the need for extra API.
Cool. We are on the same page... now we just need to determine if it
is the correct page ;)
> For example, perhaps we could communicate maxIdleTimes via
> naming conventions rather than API:
>
> session.putState("session:maxIdleTimeMs",new Integer(60000));
I think that if we are going to have common well understood data like
this, we should just add it directly to the Session interface. In
gernonimo used this kind of encoded string APIs, and it was a big
PITA, as it means we can use IDE tools to figure out who is setting
data.
> I still don't know if this approach can help with event notification,
> but I defer that until I have a quasi-working session manager against
> the API.
My guess is we're going to need to add an event notification system
to the Session APIs. What do you think about just crib off of the
servlet ones. I think we could just smash the three session listener
interfaces into something like this:
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeRemoved(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getValue();
}
We would bind a listener with a method on the Locator:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
What do you think?
-dain
Re: Session API, was: heads up: initial contribution of a client
API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> Object value = session.getState("web:/context-" + name);
Ok I get it now.
Don't have a deep - hard to replicate - structure.
Have a flat structure, but with a scoped name space!
I think this approach solves a lot of issues and probably
reduces the need for extra API.
For example, perhaps we could communicate maxIdleTimes via
naming conventions rather than API:
session.putState("session:maxIdleTimeMs",new Integer(60000));
I still don't know if this approach can help with event notification,
but I defer that until I have a quasi-working session manager against
the API.
cheers
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by James Strachan <ja...@gmail.com>.
On 3 Mar 2006, at 02:17, Dain Sundstrom wrote:
> On Mar 1, 2006, at 11:54 PM, Greg Wilkins wrote:
>> Dain Sundstrom wrote:
>>>> Now the above could be modelled with deep structure for the
>>>> state associated with an ID, but not if all state for an ID
>>>> has to be in one location.
>>>
>>> Having all of the state for a single session located on a single
>>> machine is a design assumption. We felt that if you wanted to
>>> let the
>>> data be divided across several machines it was not a single session
>>> session.
>>
>> But it is a common deployment to have the EJB on a different
>> server to the web contexts ( I know it is not optimal )
>>
>> If the session beans are going to be keyed under the same
>> session id, then the one location does not work.
>>
>> If that's not a concern having the session ID map to
>> a map of context to session is good for the web
>> tier (aside from passivation concern).
>
> I think these are two different sessions. To me a session is a
> bucket of data for a single client, and that bucket can't be
> split. You do bring up a good point though. We need a way to make
> sure that when you are in a session on one server and pass invoke
> an ejb on another server that we do not use the same ID for the
> sessions.
Yeah. There's always the option that you have 2 completely separate
Locator's which manage different physical systems so that the same
session ID can be used in each without issues. So you either lump all
the session data from web/JBI/SCA/EJB into one Session object (and so
co-locate it all) or you split it into different logical Locators and
locate it wherever you like.
James
-------
http://radio.weblogs.com/0112098/
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 1, 2006, at 11:54 PM, Greg Wilkins wrote:
> Dain Sundstrom wrote:
>>> + passivate ALL sessions (suspending node)
>>
>> That would happen under the covers of the session API (i.e.,
>> implementation specific)
>
> So if web container wants to undeploy a single context
> how does it passivate just one context in the map of maps?
> or how does the implementation know that it should passivate
> that?
>
> I guess the implementation could not passivate anything
> until all contexts are undeployed. But I'm still not sure
> how the web container tells the implementation that is undeploying
> sessions, but wants the contents saved for a later redeploy?
>
> I'm not overly concerned about this as (un)deployment is
> something that is going to involve more than just the
> session manager - but I still think a standard API for
> it would be good.
This is a tradeoff decision. If we (the community), really thinks
having the ability to handle this undeploy situation is wroth the
complexity in the API then we add it.
My personal opinion is we don't need this and I think it would be
super complex to implement. I think it would require all servers
deciding to remove an application at once.
>>> Now the above could be modelled with deep structure for the
>>> state associated with an ID, but not if all state for an ID
>>> has to be in one location.
>>
>> Having all of the state for a single session located on a single
>> machine is a design assumption. We felt that if you wanted to
>> let the
>> data be divided across several machines it was not a single session
>> session.
>
> But it is a common deployment to have the EJB on a different
> server to the web contexts ( I know it is not optimal )
>
> If the session beans are going to be keyed under the same
> session id, then the one location does not work.
>
> If that's not a concern having the session ID map to
> a map of context to session is good for the web
> tier (aside from passivation concern).
I think these are two different sessions. To me a session is a
bucket of data for a single client, and that bucket can't be split.
You do bring up a good point though. We need a way to make sure that
when you are in a session on one server and pass invoke an ejb on
another server that we do not use the same ID for the sessions.
>>> Session Management
>>> ==================
>>> There is nothing in the API to help with session management.
>>> Specifically:
>>>
>>> + last access time
>>> + access session (without actually modify state)
>>> + invalidate session
>>> + session timeouts
>>> + session events (eg session invalidation, passivation etc.)
>>
>>
>> Other than last access time, I would classify this as implementation
>> specific. The goal was to create a very very simply API that
>> OpenEJB,
>> ServiceMix, Lingo, Tuscany and web containers could use without
>> haveing
>> to know the internal details of the implementation. Does you code
>> specifically need this or it is a nice to have? If it is the
>> former,
>> can you be a lot more specic on what the terms above mean (I'm not a
>> web expert) :)
>
> These are all MUSTs as they are part of the servlet spec.
>
> Traditionally when clustering http sessions, it is the last access
> time that is the big PITA. It is updated on every request even if
> it does not ask for the session object. I guess the access time
> could
> be updated by a call to getSessionLocation, but that could make
> management difficult. Note that you don't want to put
> access time in with the other state, else you end up replicating
> the whole session state on every request.
That is how I was thinking it would be done.
> The spec also requires that a session timeout be set in the
> web.xml and via the HttpSession API for an individual session.
> So my session manager will need a way to pass that to the
> implementation.
>
> Finally if the impl decides to passivate a session (for
> any number of reasons) then HttpSessionActivationListeners must
> be notified.
>
> So if I'm to write a SessionManager that just uses this
> API, then it needs something for all of the above.
Sounds good. Can you propose some specific APIs? Also a little spec
on what the apis are supposed to do would really help. I know this
stuff can quickly go into the "gray area" :)
>>> Locking
>>> =======
>>> I'm also not sure about the semantics of release(). If I'm
>>> writing a session manager, I'm not sure if I should be making
>>> the decision of when to release - that is very much implementation
>>> dependent. Some will replicate/sync on a setState, others will
>>> do it at the end of every request, other will do it every n seconds
>>> others will do it when the session is idle (has no requests).
>>>
>>> Instead of commanding "release", perhaps the API should allow
>>> the concept of a thread entering and existing a session scope:
>>>
>>> runInSessionScope(Runnable doSomething
>>>
>>> or
>>>
>>> enterSessionScope()
>>> leaveSessionScope()
>>>
>>> individual implementations can decide what locking they
>>> implement behind the scenes.
>>
>>
>> That is exactly how the API works. When you start using a
>> session you
>> need to acquire it using the Locator and when you are done using it,
>> you release it. This is reference counting, and when the count
>> reaches
>> zero we are in a stable state and can replicate. Here is a test
>> case
>> that shows normal usage:
>>
>> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
>> test/org/apache/geronimo/session/SessionTest.java
>
> OK - but when does the reference get incremented?
> getSessionLocation,
> getSession or add/remove/get state?
getSession
> As a servlet request will update state (access time) simply by
> having the session ID, I think it would be good to have an explicit
> call to take the lock (or the runnable style).
The getSession call is what grabs the lock. As long as you have a
Session object you are considered to be working with it.
Not sure what you want changed. Can you be more specific?
> I've thought of something else related to this - I see that
> the API allows a value to be mutable after a call to
> addState or getState
>
> ie if the value is changed after the call to addState, but before
> the release, is the new value the one persisted/replicated/etc.
>
> This is mostly good - except that it will make it very
> difficult to have an efficient implementation. Many
> current web clustering solutions work with the convention
> that unless setAttribute is called, then state is not
> persisted/replicated/etc. They effectively make setAttribute
> pass by value.
>
> The reason for this is that most seasons are read mostly
> and most requests will just do the equivalent of:
>
> SessionLocation location = locator.getSessionLocation(id);
> Session session = location.getSession();
> Map state = (Map) session.getState("web:/context");
> Object value=state.get(name);
> session.release();
If you want to replication individual session entries (like most
clusters do). You will have to keep your entries at the flat level
like this:
SessionLocation location = locator.getSessionLocation(id);
Session session = location.getSession();
Object value = session.getState("web:/context-" + name);
mutate(value);
session.getState("web:/context-" + name, value);
session.release();
This should be natural to users of the API that are have used the
http session api. One of the goals was to keep the learning curve low.
> But the session impl will not know if any modification has
> been done between the getState and the session.release(). So
> on every release, the entire session must be compared to a saved
> version of it's previous value and if differences are found then
> the session is persisted/replicated/etc.
>
> So this API cannot support the conventional solution of
> using HttpSession.setAttribute to signal a modificaton.
>
> If the API had an acquire(boolean forUpdate) method, then
> this signalling could be done.
>
> Also, it will be difficult to implement an incremental
> implementation that just persists/replicates the one attribute
> that has been changed, as the deep structure hides access to
> individual attributes.
<See above>
>>> Policy
>>> ======
>
> I'll answer policy in a separate email.
>
>
>>> positive suggestions is if I try to use the jetty6 module to
>>> implement a session manager based on this API and then make changes
>>> to make it work.
>>
>> I would prefer that we discuss the API changes first. There are many
>> uses for this API and I want to keep them simple and avoid making
>> them
>> to servlet centric.
>
> Sure - I'm just saying that instead of trying to design perfection
> in a vacuum, I'll start writing a session manager that uses the API
> and that will help find problems and try alternate solutions.
>
> The API is close enough that the core functionality of web sessions is
> going to work, so it is worth starting using it I think.
I agree, I just want to discuss the changes first as this API will be
core to several projects, I think it is critical that we review and
then commit.
-dain
Session API, was: heads up: initial contribution of a client API
to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> Wow, this is a lot to digest. I'll attempt, but we may want to deal
> with these one by one...
Sorry about the length, but I'll try narrow this response....
>> + Does session ID x exist for context y
>
> In this case, I would say you lookup the session "x" and then see if it
> has an entry for context "y"
This may work and is what I meant by "deep structure", but I
have concerns about passivation and different types of session (see below).
>> + passivate ALL sessions (suspending node)
>
> That would happen under the covers of the session API (i.e.,
> implementation specific)
So if web container wants to undeploy a single context
how does it passivate just one context in the map of maps?
or how does the implementation know that it should passivate
that?
I guess the implementation could not passivate anything
until all contexts are undeployed. But I'm still not sure
how the web container tells the implementation that is undeploying
sessions, but wants the contents saved for a later redeploy?
I'm not overly concerned about this as (un)deployment is
something that is going to involve more than just the
session manager - but I still think a standard API for
it would be good.
>> Now the above could be modelled with deep structure for the
>> state associated with an ID, but not if all state for an ID
>> has to be in one location.
>
> Having all of the state for a single session located on a single
> machine is a design assumption. We felt that if you wanted to let the
> data be divided across several machines it was not a single session
> session.
But it is a common deployment to have the EJB on a different
server to the web contexts ( I know it is not optimal )
If the session beans are going to be keyed under the same
session id, then the one location does not work.
If that's not a concern having the session ID map to
a map of context to session is good for the web
tier (aside from passivation concern).
>> Session Management
>> ==================
>> There is nothing in the API to help with session management.
>> Specifically:
>>
>> + last access time
>> + access session (without actually modify state)
>> + invalidate session
>> + session timeouts
>> + session events (eg session invalidation, passivation etc.)
>
>
> Other than last access time, I would classify this as implementation
> specific. The goal was to create a very very simply API that OpenEJB,
> ServiceMix, Lingo, Tuscany and web containers could use without haveing
> to know the internal details of the implementation. Does you code
> specifically need this or it is a nice to have? If it is the former,
> can you be a lot more specic on what the terms above mean (I'm not a
> web expert) :)
These are all MUSTs as they are part of the servlet spec.
Traditionally when clustering http sessions, it is the last access
time that is the big PITA. It is updated on every request even if
it does not ask for the session object. I guess the access time could
be updated by a call to getSessionLocation, but that could make
management difficult. Note that you don't want to put
access time in with the other state, else you end up replicating
the whole session state on every request.
The spec also requires that a session timeout be set in the
web.xml and via the HttpSession API for an individual session.
So my session manager will need a way to pass that to the
implementation.
Finally if the impl decides to passivate a session (for
any number of reasons) then HttpSessionActivationListeners must
be notified.
So if I'm to write a SessionManager that just uses this
API, then it needs something for all of the above.
>> Locking
>> =======
>> I'm also not sure about the semantics of release(). If I'm
>> writing a session manager, I'm not sure if I should be making
>> the decision of when to release - that is very much implementation
>> dependent. Some will replicate/sync on a setState, others will
>> do it at the end of every request, other will do it every n seconds
>> others will do it when the session is idle (has no requests).
>>
>> Instead of commanding "release", perhaps the API should allow
>> the concept of a thread entering and existing a session scope:
>>
>> runInSessionScope(Runnable doSomething
>>
>> or
>>
>> enterSessionScope()
>> leaveSessionScope()
>>
>> individual implementations can decide what locking they
>> implement behind the scenes.
>
>
> That is exactly how the API works. When you start using a session you
> need to acquire it using the Locator and when you are done using it,
> you release it. This is reference counting, and when the count reaches
> zero we are in a stable state and can replicate. Here is a test case
> that shows normal usage:
>
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
> test/org/apache/geronimo/session/SessionTest.java
OK - but when does the reference get incremented? getSessionLocation,
getSession or add/remove/get state?
As a servlet request will update state (access time) simply by
having the session ID, I think it would be good to have an explicit
call to take the lock (or the runnable style).
I've thought of something else related to this - I see that
the API allows a value to be mutable after a call to
addState or getState
ie if the value is changed after the call to addState, but before
the release, is the new value the one persisted/replicated/etc.
This is mostly good - except that it will make it very
difficult to have an efficient implementation. Many
current web clustering solutions work with the convention
that unless setAttribute is called, then state is not
persisted/replicated/etc. They effectively make setAttribute
pass by value.
The reason for this is that most seasons are read mostly
and most requests will just do the equivalent of:
SessionLocation location = locator.getSessionLocation(id);
Session session = location.getSession();
Map state = (Map) session.getState("web:/context");
Object value=state.get(name);
session.release();
But the session impl will not know if any modification has
been done between the getState and the session.release(). So
on every release, the entire session must be compared to a saved
version of it's previous value and if differences are found then
the session is persisted/replicated/etc.
So this API cannot support the conventional solution of
using HttpSession.setAttribute to signal a modificaton.
If the API had an acquire(boolean forUpdate) method, then
this signalling could be done.
Also, it will be difficult to implement an incremental
implementation that just persists/replicates the one attribute
that has been changed, as the deep structure hides access to
individual attributes.
>> Policy
>> ======
I'll answer policy in a separate email.
>> positive suggestions is if I try to use the jetty6 module to
>> implement a session manager based on this API and then make changes
>> to make it work.
>
> I would prefer that we discuss the API changes first. There are many
> uses for this API and I want to keep them simple and avoid making them
> to servlet centric.
Sure - I'm just saying that instead of trying to design perfection
in a vacuum, I'll start writing a session manager that uses the API
and that will help find problems and try alternate solutions.
The API is close enough that the core functionality of web sessions is
going to work, so it is worth starting using it I think.
cheers