geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Fri, 03 Mar 2006 18:25:56 GMT
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.


View raw message