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/
