>>> Satish Kamatkar <[EMAIL PROTECTED]> 9/24/99 12:50:00
AM >>>
>In the following hypothetical architecture, with Servlets sitting on
the App
>Servers machines ( pool of app servers residing on different
physical
>machines), is there any issues using Session objects to store
client
>information?
Oh yes. You need some kind of session sharing system across the
servlet engines (such things do exist but they're expensive I
believe).
The new 2.2 API has something on this so servlet-engines might start
supporting this more when it becomes standard. Check the Sun servlet
pages for more info.
>If client A is being served from the ServletA of AppServerA which
stored the
>shopping cart for client A and then in the next request, client A is
being
>served from the ServletA of AppServerB, would the ServletA residing
on
>AppServerB be able to retrieve the correct session objects?
Sessions remain local to the ServletContext where they originated
from.
You could fix this by implementing SessionManager yourself (to store
session on some common DB).
But there is a much simpler fix... ensure that users who have a
session return to the same servlet engine for each request... as soon
as the session is invalidated (either the users performs some log out
operation or the session times out) then the user can be relocated to
another servlet engine.
We do this for Talk21 (BT's free email system). We also use a network
device called a Local Director to map a single domain name to many
servlet engines in a round robin kind of way... of course you could do
that with a front-end servlet as well....
Nic Ferrier
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
