Sorry, but I just don't see the need for transparent failover in most cases. I don't believe many web applications have unsaved state over more than a few requests. So yes, you lost a server and you have to login again, but so what? It's not like it's going to happen very often to a single user. Sticky sessions for teh win! ;-)
And once you remove the need for session state replication the whole argument for client side state just crumbles. Unless you do something like gwt does. But that's really not a web application anymore, but a fat client based on a crappy toolkit (compared to something like Swing or Eclipse RCP). I don't believe Wicket is what you want, then and I don't think Wicket should try to serve that space. Thomas >> What is this data juggling you talk of? If you use sticky sessions >> (which is really necessary for any serious web application IMO) there >> should not be any data juggling. > > But if you need failover, you need a buddy system, because session sharing > across multiple clusters is not that desirable or fast. You eliminate the > necessary data-juggling by using an inferior way of failover. Because you > need more memory and more processing power and LAN traffic to keep the state > synchronized, you simply need more iron to serve your web application. So, > you need to scale out to larger clusters earlier. It's cheaper and faster to > keep the state at the client. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
