scope of servletContext

[muttley]

hi,

I've hit a peculiar problem trying to solve a requirement in a web app
It requires a batch routine to be fired at a particular time, yet be
controllable via the application.
I solved this by creating a runnable class and a thread to run it,
storing references to both on servletContext, then using standard
jsp/bean code to manipulate it.
starting and stopping the routine using software and command line
service tomcat5 stop / start
works, and the existing thread disappears and reappears when the
website is next logged into.
When there are no users logged in and the application is redeployed by
a war, the context check during login does not find the existing thread
or bean reference so creates a new one (it normally finds the ref and
skips creating one).

1) how would you approach the batch run problem

2) what happens to servletContext when you re-deploy with a war?

any bright ideas welcome

 

[John C. Bollinger]

I've hit a peculiar problem trying to solve a requirement in a web app
It requires a batch routine to be fired at a particular time, yet be
controllable via the application.

That sounds a bit weird. What does "controllable via the application"
mean, and how is that consistent with the job being a "batch routine"?

I solved this by creating a runnable class and a thread to run it,
storing references to both on servletContext, then using standard
jsp/bean code to manipulate it.

What kind of manipulations do you have to perform?

starting and stopping the routine using software and command line
service tomcat5 stop / start
works, and the existing thread disappears and reappears when the
website is next logged into.

Well that's odd -- in the sense that it doesn't seem consistent with the
requirements, that is. What if no user logs in between the restart and
the next scheduled time for the job to run? Is this part of your problem?

When there are no users logged in and the application is redeployed by
a war, the context check during login does not find the existing thread
or bean reference so creates a new one (it normally finds the ref and
skips creating one).

That sounds reasonable.

1) how would you approach the batch run problem

Do you mean in general, or are you asking for recommendations about your
own program's observed behavior? I'll attempt to answer the first
(below), because it's not clear to me what you think is right or wrong
about what your app is doing now.

2) what happens to servletContext when you re-deploy with a war?

I would expect the original servlet context to be shut down and
discarded, and a new one created. The container might or might not
attempt to carry over live sessions, and that behavior might be
configurable. It also might or might not attempt to carry over servlet
context attributes, in which case it is unlikely to succeed with any
attribute that is not Serializable. The worst possible case is that on
a hot redeployment your thread continues to run, but the new servlet
context has no reference to it. To avoid that you should make sure that
your thread is made to shut down (gracefully, one hopes) when the
servlet context is stopped but the container keeps running.


In general, web application components that are autonomous should not be
initialized by client activity. The appropriate means to initialize and
start such components is usually to create and configure a
ServletContextListener implementation. Such an object also gives you a
hook for shutting down such components when the application is stopped,
including during a hot redeployment.

In your place, I probably would not have created my own Thread to handle
scheduling, but instead used a java.util.Timer. You might be able to
switch over fairly easily by making your custom Runnable extend
java.util.TimerTask. It is an open question whether I would have made
the scheduler part of the webapp at all; an alternative would be to make
it a standalone application exposing some mechanism for the webapp to
use to communicate with it (socket, fifo, signal, etc.). Much depends
on the details, but if reliable scheduling of the job is more important
than the web interface to it then that's an argument in favor of
standalone scheduling.


I hope that helps.