Here is a scenario of an application that uses HttpSession and caches
application data on that session which may encounter a serious
problem due to the potential loss of the data on that HttpSession when using it with
load balancing.
A possible scenario is as following:
2 web servers A,B and a load balancer (local director ) C that balances requests
made from browsers to the appropriate web server according to the load on each box.
Say each web server capacity is 50 users and there are 50 users logged to server A.
Due to some time-out (browser/transport layer) a user stops interacting with A and
instead a subsequent user is assigned to A . When the original user that timed-out due
to the transport layer tries to proceed his session (with possibly valid HttpSession)
he is assigned to server B since A is in full capacity (50) .
The user that may be in the middle of a transaction - expects to be able to proceed
with the data that was cached on the HttpSession, yet, the user was assigned by the
load balancer to a second web server (B) and therefore the HttpSession information is
lost.
Note: maintaining cached application information on the Httpsession enables saving
many calls to the database to re-retrieve that data and therefore saves a substantial
amount of time.
The question: is there a way to force a load balancer to maintain a browser's session
that started with a web server (as long as it didn't time-out due to the server
session time-out ) to persist with that web server ?
This persistence can expire when the user's HttpSession expires. (and the load
balancer needs to know it so it can assign another user instead for that web server ).
If this isn't possible how ,then , do applications that use session management
overcome a load balancing "intervention" that may invalidate a session that a browser
maintains with a web server ? if the user/broswer is re-routed to a different web
server ?
This must be a typical scenario in an application that uses session mgmt. and load
balancing ...
Thanks
Ari
[EMAIL PROTECTED]
Please trim the preceding _nospam_
___________________________________________________________________________
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
