Java Beans - Application Scope exit

Author

Application Scope exit

Jeremy

2005-02-05, 3:57 am

Sorry if this is super obvious, but I have been searching for a w

without finding a solution.

I want to use an application scope bean that will, after a certain
amount of elapsed time, die/kill itself/release its
memory/whatever...just go away, leaving no trace of itself running. I
have setup a TimerTask that calls System.exit(0) but that exits the
whole application server!! Not what I had in mind. Instead I just
want the application to exit and free up its memory. Something like
Application.exit(0);

Can this be done somehow? Code follows:

package TestExit;

import java.util.Timer;
import java.util.TimerTask;
import javax.servlet.http.HttpServlet;
public class TextExitBean extends HttpServlet {
int SECONDS = 5 * 1000;
Timer timer;

public TextExitBean() throws Exception {
System.out.println("Starting Bean");
timer = new Timer();
timer.schedule(new RefreshDataTask(),SECONDS);
}

class RefreshDataTask extends TimerTask
{
public void run()
{
timer.cancel();
System.out.println("Exiting Bean");

// Instead of System.exit,
// I want to do something like Application.exit(0);
System.exit(0);
}
}
}

Thanks in advance!
Jeremy

John C. Bollinger

2005-02-07, 4:01 pm

Jeremy wrote:

> Sorry if this is super obvious, but I have been searching for a w

> without finding a solution.
>
> I want to use an application scope bean that will, after a certain
> amount of elapsed time, die/kill itself/release its
> memory/whatever...just go away, leaving no trace of itself running. I
> have setup a TimerTask that calls System.exit(0) but that exits the
> whole application server!! Not what I had in mind. Instead I just
> want the application to exit and free up its memory. Something like
> Application.exit(0);

You are chasing a red herring. Objects do not "run". They consume no
CPU at all, ever. Objects do define, chiefly by means of their methods,
work that the *JVM* _may_ expend CPU cycles to perform. If there is no
possibility that any of a particular object's methods can be invoked,
then it is "garbage", and will presently be discarded by the JVM's
automatic storage manager (garbage collector). If, on the other hand,
some of the object's methods might be invoked, then it is incorrect (and
impossible) to discard the object. You might set up a timer to
"disable" the object after some delay (for some definition of
"disable"), but I cannot imagine very many circumstances where that
would be useful.

John Bollinger
jobollin@indiana.edu

Jeremy

2005-02-09, 3:58 pm

Thanks John,

Your answer certainly clears up some of my confusion.

The issue arises from the fact that when I redeploy my application to
the app server (Oracle 10g) it never releases the memory of the
previously deployed bean. I don't believe that any methods in the old
version of the bean will ever be called again (since I've redeployed a
newer version), but it never gets garbage collected.

Do you know of some mechanism for deploying the same application over
itself that will un-deploy the old version?

Thanks again,
Jeremy

John C. Bollinger

2005-02-09, 3:58 pm

Jeremy wrote:

> The issue arises from the fact that when I redeploy my application to
> the app server (Oracle 10g) it never releases the memory of the
> previously deployed bean. I don't believe that any methods in the old
> version of the bean will ever be called again (since I've redeployed a
> newer version), but it never gets garbage collected.

I gave you a simplified definition of "garbage" from a functional
viewpoint, which may have been a mistake. If it turns out that that was
confusing then I apologize. Let me give you a version closer to the
language spec's: an object is eligible for garbage collection if it
cannot be reached by a live thread through a chain of strong references.
Under those circumstances its methods cannot be invoked (except by the
garbage collector itself), and under any other circumstances they
potentially can be; that's how I arrived at the approximate definition I
offered earlier.

> Do you know of some mechanism for deploying the same application over
> itself that will un-deploy the old version?

Whether or not redeploying the application does (or should) undeploy the
currently deployed version is in the realm of application server
details. If the redeployment does not (or doesn't fully) undeploy the
old version then you might indeed have the problematic bean lying around
in memory indefinitely.

You should also consider that even though the bean may become _eligible_
for GC, there are no guarantees about when or even whether it will _be_
GC'ed. If you have significant system resources tied up in the bean
then you should not be relying on GC to free them. You might consider
how to avoid making the bean do that. Alternatively, you might consider
a slightly different design: (this is a regular bean, right? not an
EJB?) have the bean class implement ServletContextListener, and register
it (in web.xml) as a listener. When it is notified of application
startup it can add itself to the ServletContext (equivalent to
registering an application scope bean) and when it is notified of
application shutdown it can free up any scarce system resources it is
holding.

--
John Bollinger
jobollin@indiana.edu

Sponsored Links