From the research I have done on other sites about mod_jk and my own experience testing mod_jk with Glassfish and Tomcat, I have determined the following:
mod_jk does not keep a store of session ids. It merely looks at the .jvmRoute extension that is appended to the sessionid to determine which worker to send the request to. It was implemented this way so that multiple apache servers could load balance the same set of tomcat servers. (for apache fail-over purposes) [i]If it did keep a store of session ids and what worker created them, then we would not be having this discussion![/i]
In Tomcat, the workers still keep track of the session via the base sessionid. The .jvmRoute seems to be added for mod_jk's benefit only. If sessions are replicated, they are replicated using the base "jsessionid" and not "jsessionid.jvmroute"
In Apache, if a worker is unavailable, mod_jk will pick a fail-over worker based on how mod_jk is configured. When this happens, there are two possible outcomes:
a) If the original worker is a Tomcat worker and the session data is replicated to other Tomcat workers, then the fail-over worker finds the base sessionid in its store and carries on replacing the original worker's .jvmRoute with its own.
b) the session data is not replicated to the other workers, and the fail-over worker starts a new session and the previous session is lost. (usually resulting the user having to log back into the application)
I believe the interest here is in allowing for a gradual transition from Tomcat to Glassfish and/or maintaining Apache as a load balancing front-end.
I suppose this means implementing .jvmRoute is not as simple as once thought.
[Message sent by forum member 'jakemann' (jakemann)]
http://forums.java.net/jive/thread.jspa?messageID=241982