I want to clarify how classes behave in the Tomcat environment (and presumably other persistent-JVM environments) when they are changed and redeployed. If I have an instance of a class, A, executing in the Tomcat environment and which is running in application scope (i.e. it will not go out of reference in the lifetime of the application), and I then change A and redeploy, what does Tomcat do? Does it: (1) attempt to free the first instance and replace it with the second (seems unlikely and rather risky as far as losing data is concerned) (2) attempt to execute the two simultaneously with any _new_ references made to the object going to the new one (seems most likely) (3) simply continue executing the first and not expose the changes until the container is restarted? (4) do something else entirely
If the second or third cases are true, is there any way of getting the container to signal the "old" instance of A to tell it it's no longer up-to-date and suggest it clean up, pack its bags, and get out of there, and then hand off any further requests to a "new" instance? In case it helps as a reference point, a good instance of this is where you use a singleton class to handle, e.g, database access (or logging, etc.). If the singleton is changed and redeployed, how does Tomcat behave? And if the first instance is using resources the second needs, how can this contention be resolved? Hope some of that makes a little bit of sense! Chris -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>