Caldarale, Charles R wrote:
Also be aware that any static fields or singleton objects in the shared classes
really will be shared by each webapp, whereas before each webapp had its own
copy.
You must have meant "shared by all webapps". Chuck, you should really
watch your usage of the terminology here.
;-)
Being ever eager to learn, I have been following this thread with interest.
Do I understand this correctly, if I draw the following conclusions :
- the Heap is a global structure, managed by the JVM which runs Tomcat
- webapps create (instantiate) objects by using classes, which are
pieces of code which (among other things) create objects. Such objects
are allocated on the Heap.
- instances (copies) of classes are loaded into JVM memory (where?) on
an "as-needed" base, for example the first time a webapp invokes some
piece of code in the class
- a class instance can be loaded from
- either a location private/belonging to a particular webapp
(WEB-INF/classes/*.class or WEB-INF/lib/*.jar)
- or a location common to all webapps, such as
Tomcat_dir/shared/classes or Tomcat_dir/shared/lib/*.jar
- The JVM "remembers" where a class instance was loaded from, so that
for example an instance of class A loaded from
webapp-1/WEB-INF/lib/abc.jar is distinct from an instance of class A
loaded from webapp-2/WEB-INF/lib/abc.jar, and both are different from an
instance of class A loaded from Tomcat_dir/shared/lib/abc.jar
- it would be a bad idea anyway to have abc.jar located in a
webapp-x/WEB-INF/lib and simultaneously in Tomcat_dir/shared/lib.
(Why this is a bad idea is not very clear to me if the above holds true,
but I trust previous communications here saying that it is a bad idea)
- an object always holds a reference to the class it was created from
- a class instance generally does not, but can, keep a reference to the
objects created from it. Class instances which create a singleton object
perforce keep a reference to it.
- a class instance can be unloaded from memory when
- the webapp which loaded it is itself unloaded, and all objects of
that class created by (or belonging to) that webapp are thus destroyed
- AND the class instance does not contain any reference to any other
object(s) created by (an)other webapp(s)
In other words, if a class instance was loaded from a jar in
Tomcat_dir/shared/lib, then
- that class instance would be shared by all webapps referencing the
class, and would only be allocated once in memory (?) (thus saving
memory space)
- but that class instance could not be unloaded (and maybe replaced by
another better version) until all objects created by it, on behalf of
any webapp, have been destroyed. In the practice, this could mean that
it is only possible to unload and reload this class instance by stopping
and restarting the entire JVM (and Tomcat).
Thus, if one is confident that all webapps are compatible with the same
version of some classes, and if these classes do not contain class-level
variables or allocate singleton objects whose common usage by different
webapps may lead to trouble, and if one never intends to unload/reload a
single webapp at a time and always brings down and restarts the whole
Tomcat at once, one might as well put the classes in Tomcat_dir/shared.
And if in doubt about any of the above, put them in each webapp's
WEB-INF and buy more RAM if necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
