I'm looking at issues concerning distributed architecture and found this description from an exerpt of Jason Hunter's 'Java Servlet Programming' under 'Many Styles of Distribution' :
"2. Clustering support, no session migration, and no session failover. Servlets in a web application marked <distributable/> may execute across multiple machines. Nonsession requests are randomly distributed (modulo some weighting perhaps). Session requests are "sticky" and tied to the particular backend server on which they first start. Session data does not move between machines, and this has the advantage that sessions may hold nontransferable (non-Serializable) data and the disadvantage that sessions may not migrate to underutilized servers and a server crash may result in broken sessions. This is the architecture used by Apache/JServ and Apache/Tomcat. Sessions are tied to a particular host through a mechanism where the mod_jserv/mod_jk connector in Apache uses a portion of the session ID to indicate which backend JServ or Tomcat owns the session. Multiple instances of Apache may be used as well, with the support of load-balancing hardware or software." My questions about this: 1. I'm assuming that with a single Apache server that it has mutltiple Tomcat servers that it balances across therefore knowing which session to send where but how is a "sticky" session achieved with mutliple Apache instances? The last sentence suggests this is possible. 2. Is using a single Apache server serving across multiple Tomcats and having another Apache server connected to the same Tomcats as a standby if the first goes down an effective solution for high availability? I'm not too concerned with migrating sessions or session failover as long as a session is continued (meaning the request goes to the same Tomcat instance). Currently I'm looking into persistent storage on a database but I worry it's too costly (timewise). Please let me know what can I expect from Apache/Tomcat combination in a distributed environment without going the EJB, big-ass-expensive application server route. Thanks, d. -- David Mossakowski [EMAIL PROTECTED] Instinet Corporation 212.310.7275 ******************************************************************************* <<Disclaimer>> This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL or both. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently deleting the copy you received. Thank you. ******************************************************************************* ___________________________________________________________________________ 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
