I'm looking to use tomcat in a 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).

-- Bottom Line --
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, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to