Brian,
My understanding of servlets also indicates that instantiating a CLASS
instance in init() should produce a single persistant object of that class
(accessible in doGet() & doPost()).
When a servlet instance is created it persists for the life of the server.
(This is not a developer feature, but a general feature - and should hold
true for most Java Web servers).
If you instantiate a CLASS variable in the init() method of a servlet the
object should also persist for the life of the server.
I'm afraid I can't explain why there is the same overhead when
instantiaiting in doGet()/doPost() - which will create a new object for
every request. This should be less efficient??
Regards,
Andy
-----Original Message-----
From: Brian Maschhoff [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 04, 2000 4:33 PM
To: [EMAIL PROTECTED]
Subject: RE: Object Caching Problem
Andy (or anyone else),
Do you know if the developer edition of JRun reuses servlet instances as
well?
Specifically, I am trying to take advantage of the feature you've described
by overriding the init() method. I have an instance variable (a rather
complicated class) that I create an instance of in the servlet init().
Given the overhead, I want to create this object as seldom as possible.
I've tried this using the developer edition, but it doesn't seem to offer
any improvement over instantiating the class in the doGet() or doPost().
Am I missing something?
Brian
>>> [EMAIL PROTECTED] 08/04/00 02:52AM >>>
Bill,
Your description of the way the JRUN server is behaving is correct.
This is not an error with the server, but an feature of the server - and in
fact the product of one of the key benefits of servlets over traditional
CGI.
My understanding of a java web server may help you (sorry about the
woffle!):
When a servlet is first loaded (either at server start-up or first servlet
request) the server creates a SINGLE instance of that servlet class. The
object then persists on the server and is used to handle each request to
that servlet. (i.e there is generally only ever one single instance of a
servlet during the entire life-cycle of the server). For each request a new
thread is created by the servlet which handles the service methods (incl.
doGet() setc). The benefits of this are:
- no over-head for servlet object creation once it has been loaded
- smaller memory foorprint
There is a further optimisation which determines whether a servlet is
dynamically reloaded when it changes. IF the servlet is in the servers
classpath it will not be reloaded if the servlet class changes UNLESS the
server is restarted. (This removes the need for the server to constantly
check for updated versions of a servlet every time its service methods are
called).
However, there is a neat trick which allows you to place a servlet in the
(default) servlets directory (root/servlets/), and will cause the servlet to
be reloaded if its time-stamp has changed. (This feature is there for
developers). However, the servlets support classes are not checked by the
server for changes. Instead, the new support classes will only be updated
IF the calling servlet's time stamp is changed and the servlet is re-laoded
-
Therefore the answer to your question is:
Place all your servlets/support classes in the servlets directory, and
recompile the servlet if:
- the servlet changes
- the servlet's support classes change
An interesting point to note here is that if you have two servlets which
call the same support class, and you change the support class and only
compile (update) one of the servlets - then the servlet that was not
re-compiled will still use the old version of the support class.
Hope this helps.
Andy Phelps
-----Original Message-----
From: Shelton, William D [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 03, 2000 5:04 PM
To: JRun List (E-mail) (E-mail)
Subject: Object Caching Problem
Hi List:
I'm new to JRun and somewhat new to Java, so please bear with me.
Symptom:
When I make changes to a class in a package, those changes are not reflected
in the calling servlet or JSP page UNLESS I restart the JRun Server. In
fact, I get a java.lang.NoSuchMethodError
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Simplified Package Code: */
package mystuff;
public class Person{
protected String firstName = null;
Person(){}
public void setFirstName( String fName ){
this.firstName = fName;
}
public String getFirstName(){ return this.firstName; }
} //end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The above simple code works fine when I call it from a servlet or JSP page
like so:
import mystuff.*;
import other.packages.*;
// snip ...
Person p = new Person();
p.setFirstName( "James" );
out.println( p.getFirstName() );
...
However, if I update this class to ALSO include:
protected String lastName = null;
public void setLastName( String lName ){
this.lastName = lName;
}
public String getLastName(){ return this.lastName }
...
Then when I invoke the servlet/JSP using :
Person p = new Person();
p.setFirstName( "James" );
p.setLastName ( "Kirk" );
out.println( p.getFirstName() + " " );
out.println( p.getLastName() );
...
the servlet throws a java.lang.NoSuchMethodError ...
If I restart the server, it works fine. It seems like JRun is caching the
classes in the package or is not refreshing the package.
Am I missing something obvious? Or is this a problem with a workaround?
Thanks in advance!
Bill
----------------------------------------------------------------------------
--
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe:
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe'
in the body.
----------------------------------------------------------------------------
--
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe:
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe'
in the body.
----------------------------------------------------------------------------
--
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe:
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe'
in the body.
------------------------------------------------------------------------------
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
