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.
Filip
If we would store the result-set (list of already created beans) in
the session, we'd have to store them twice, once in the "cache" and
once in request for presentation. However, a pluggable diff object
would be great!
how you store it, once or twice is up to you, and how you code your app.
if you are storing it twice then that is a flaw in your programming, not
in tomcat nor in the session replication.
Btw, another point: The object/handler/whatever which decides whether
a session create event should be distributed at all should be
configurable/replaceable too.
Background: most or at least many hardware loadbalancer use urls for
service health monitoring. They do not send any cookies back, so in
fact each heartbit creates a new session. Our lb + failover lb are
sending heartbits each 8 seconds each. With session timeout of 30
minutes we always have 450 active lb sessions on each server.
Distributing those sessions should be considered spam and waste of
network resources :-)
as mentioned, you can choose cookie or distributed map. when you use the
cookie logic, you still need to cancel out the primary cookie in case
the lb did a false positive.
In case primary node knows, that it will go down in near future and
should send all his users away, it could stop accepting new requests
and redirect old users directly to the backup node(s). That way the
performance risk of getting sessions cross over the network could be
reduced.
What do you think about it?
this would be implementing code that is not needed. solving a problem
that is already solved doesn't help anyone.
http://people.apache.org/~fhanik/kiss.html ;)
I fully agree with the KISS principle, and follow it in my job and all
projects, that's why we never use anything we don't need, like
app-servers, or-mappers and such, until one proves, that using the
thing make the live really easier and not complicated.
Therefore I understand that implementing support for everything
everyone need and keeping the code simple are contrarian goals, but
making the code fine-graned and elements exchangeable wouldn't violate
KISS, would it?
it would only violate it if you the features are never used, and
everyone sticks with the default. then you have code that is not in place.
I usually don't write the code until there is an expressed need for it,
and I can't get that expressed need until people say they dont like the
default impl.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
