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

What kind of manipulations do you have to perform?

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?

That sounds reasonable.

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.

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.