On 22/12/2015 16:22, Jason Britton wrote: > Questions on particulars of session fail over in my on going quest for zero > downtime deployments - > > My current plan is to use JDBCStore for persisting to a database table > shared by all tomcats powering apps. But this has brought up a couple > concerns... If while a tomcat node is being shut down and triggered by > this shut down, tomcat starts writing out session data to the JDBCStore, a > request from a client that was using that node comes in, mod_jk tries to > route the request to the node that is shutting down but mod_jk's configured > connect_timeout times out waiting and mod_jk then routes to another node > (hopefully that's how this works). A different active tomcat node now > receives the request and tries to reconstitute the user's session from the > same shared JDBCStore, but what if the first tomcat node is not finished > shutting down and has not finished writing out this particular user's > session data yet? How can we ensure that session data will be there?
With the set-up you describe, you can't. If you were using clustering, you could configure the cluster to replicate any changes in the session before the request is completed. That way, for any completed request, the cluster is guaranteed to be up to date > From looking at the config of the Manager, there is a maxIdleBackup > parameter that I imagine could be set to 0 but I'm a little wary of the > possible performance implications. Its description: The time interval (in > seconds) since the last access to a session before it is eligible for being > persisted to the session store, or -1 to disable this feature. By default, > this feature is disabled. Even if this was ok from a performance > perspective, once a session was initially persisted, would its session data > be updated in the session store on subsequent changes/requests? Yes. The best way to dig into this is to look at the source code. > I've read about some folks configuring valves for shared in-memory caches > (redis), I'm not sure I want to go that route at this point. > > Any thoughts would be much appreciated, happy holidays! A custom valve that triggered session persistence at the end of every request? You'd probably need a custom persistence manager so the necessary hooks were exposed. A tomcat cluster is, essentially an in-memory, distributed session cache. If you want a pure Tomcat solution, that is probably the way to go. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
