Class lifecycle

[Chris Tucker <ct...@epangea.com>]

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:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>