On Tue, 13 Nov 2001, Paul Speed wrote: > I think the idea is that you'd byte compare on "commit" which ideally > would happen at request boundaries. So in this case a single request > becomes a "transaction"... which indeed opens up its own issues, but > no bigger than the ones that were always there.
Not good enough - when the request is completed the user already has the page confirming his order ( and maybe the card was already charged :-). > 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. And what's worse, far too many people will not realize that, and read the marketing stuff ( 'we support failover, session replication, etc') and believe it is a magic solution. > 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. I agree it would be nice to have a tool that can store objects with fail-over, distribution, etc and using it as a _complement_ to the session ( maybe using the session id, expiration, etc ). I don't think this tool can be used using only the current servlet session API or that it should be used as a servlet session manager. > distributed session environment. I think that's a given. Personally, > I'm still trying to figure out if there are a large enough number > of webapps that could be supported to make it worth the effort. > (Heavy emphasis on effort.) I'm more worried about the number of webapps that would be written with the assumption that the session will be magically safe, instead of using transactions/database/EJB/ or whatever storage API. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
