[EMAIL PROTECTED] wrote: > > 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 :-).
Yes, but that all we have are "requests" in a session. > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
