>Pier: > >Great discussion points. I really appreciate your thoughtful feedback. > >My comment about Tomcat caching session data does not preclude >it from being stored in the remote session server. Indeed, this would >be required. My thought was this, in a multi-node network if multiple >contiguous requests (for the same session) are handled by the same >tomcat node, then that tomcat node should not be forced to retrieve >a copy of the session from the session server for each request. It only >needs to go back to the session server for the session if it doesn't >have a 'valid' copy. Remember that if another tomcat instance causes >the session to be updated, then the server will tell all the clients to >invalidate that session. This caching works when intervening requests >are handled by more than one node and that do not actually update the >session attributes. > >Notice also, in my concept, there are no delays built into the >architecture >(other than the natural delays caused by sending data over the >network). >The session server can simply respond to callers on-demand.
I've discussed some time ago about this subject and adding the session stuff in the Connector, maybe webapp/warp could be tuned for this purpose. It's clear that the persistance and replication of session data is needed for HA systems, and many solves it by using the EJB backend as repository, WebSphere for example. In some case it appears also very expensive to try to add automatically this persistance (maybe something to be added to server.xml , some webapps could live without session data even, in a soft restart mode). There is also the problem of finding a fast and portable network protocol (multicast may not run on all system, Broadcast UDP need recovery code). What's the status of mod_backhand (http://www.backhand.org/) and Apache ? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
