See below ----- Original Message ----- From: "Paul Speed" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 3:48 PM Subject: Re: Tomcat: Distributed Session Management revisited
... stuff deleted ... | | The main issue is that the app has no control over this transaction. | The case where things get strange is if the JVM dies in the middle | of processing a single request. The request may have already | committed real data to the DB, app server, whatever... and yet the | session state up to the point of failure would be lost. Even five | second polling wouldn't fix that case. | | In fact, that's the same case that fails in _every_ scenario that | doesn't involve full EJB-like transaction support. As soon as you | access one single piece of data that isn't covered by the | transaction support, you lose some amount of failover recovery. | | Nothing short of full transaction support will ever cover the case | of the dying JVM... and in some rare cases I think that will even fail. Yes, let's remember the 80/20 rule. The solution to this problem will come at a very high cost (if at all). Yet, this problem (servlet container that crashes in the middle of a transaction) is a corner case. Also, remember that if someone really needs this level of protection, they are far better off implementing their business and database logic inside a (bank of) J2EE server(s), and only depending on HttpSession objects for holding transitory information (like user-inputs from a mulit-page form, or the contents of a shopping cart prior to pressing the 'Commit Order' button. ) There are plenty of high-volume web-applications that need to be HA and scalable over 'n' servers but where J2EE is overkill. This is the problem domain that I am focusing on. | | That being said, there may still be a place for a session-based | distribution mechanism that can support load balancing, hot-swapping | of tomcats, and basic failover. It should definitely be an opt-in | sort of thing though, ie: web apps that meet the restrictions can | opt to setup tomcat to provide this feature. There is great value in this. Tom -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
