That's one reason to use EJB. =) -----Original Message----- From: Kevin Duffey [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 9:50 AM To: [EMAIL PROTECTED] Subject: Developing for scalability..HttpSession fail-over... Hi all, Just wanted to see if anyone has developed an application that works and is HttpSession fail-over safe. In other words, your web.xml has the <distributable/> tag, and you can successfully deploy the application into a container and handle session level fail over so that if one of two (or more) servers craps out, the user(s) on that box are still able to have their session in existence and are routed to another server that has it alive. Now, the reason I am asking is that there is one problem I noticed when testing my application for this. Something I think alot of people don't realize that in order to be ready to scale, you have to do this. If you use JavaBeans at the session scope level, you may be used to doing something like this in say, a servlet: MyBean myBean = (MyBean) session.getAttribute("MyBean"); myBean.setFirstName("SomeName"); myBean.setLastName("AnotherName"); RequestDispatcher rd = request.getRequestDispatcher("/somepage.jsp").forward( request,response ); ----- somepage.jsp: <jsp:useBean id="MyBean" scope="session" class="somePackage.MyBean"/> <html> <head> <title>Demonstation</title> </head> <body> Welcome <%= MyBean.getFirstName() %> <%= MyBean.getLastName() %> </body> </html> This works just fine. You set the bean first and last name, forwarded to a JSP page and can display it. The problem is..since you are setting object references (and even values) on a HttpSession object, these changes are NOT reflected on another server in a cluster unless you ALWAYS reset the object back into the session. So, every time you get a bean out, you would have to add this at the end of any changes you make: session.setAttribute("MyBean", myBean); >From what I have read, the only way a server (that supports session-level failover) replicates HttpSession data is when the setAttribute() or putValue() (deprecated Servlet 2.1 call) is called upon! If you just change various references of objects in the HttpSession, this data will never get copied over to another server. Now, my point in all this is that I am wondering if anyone working with say WebLogic, WebSphere, and so on has had to program in this manner for session replication, or if those servers just do it for you? If they do..how? Because the only other way I can think of is not exactly accurate: after a set interval, copy the HttpSession to any other server in the cluster! This would suck though..because if that set interval was every 1 second, it would seriously degrade your system. If it was every say 10 to 15 seconds, a few things could change in that time in one session..and if the server crapped out, the users session on another server would not be accurate. But on the other hand, if the session is replicated every time any one user stores an object in the session, it is possible that 100 users do this every second (on a high-traffic site) and thus replication might be evern WORSE on performance at this pace, than just doing it every 1 second. Ofcourse..the last part of this...it would be worse in this case only if the entire HttpSession was replicated. If it was on a per object per user type of replication, then it would be much more effecient. So..which is it? Do servlet containers only replicate session data when code sets the object back into the HttpSession (which makes sense if it can do "smart" object replication and not serialize the entire HttpSession every time)? Do the containers serialize the entire HttpSession every time? What happens if you have 500MB of HttpSession objects in memory? Does it really try to send 500MB every time the setAttribute() is called? Love to hear some answers on this topic. =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
