tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: tomcat 5.5.25 shared lib and sharing webapp jars
Date Fri, 09 Oct 2009 21:29:15 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message