scope of servletContext

Discussion in 'Java' started by muttley, Nov 9, 2005.

  1. muttley

    muttley Guest

    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
    muttley, Nov 9, 2005
    #1
    1. Advertising

  2. muttley wrote:
    > 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.

    --
    John Bollinger
    John C. Bollinger, Nov 11, 2005
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. iksrazal
    Replies:
    1
    Views:
    607
  2. Rick Roberts
    Replies:
    0
    Views:
    381
    Rick Roberts
    Aug 10, 2003
  3. RJGraham
    Replies:
    3
    Views:
    3,309
    Huang Kai
    Nov 27, 2003
  4. natG
    Replies:
    6
    Views:
    609
  5. Replies:
    2
    Views:
    10,315
Loading...

Share This Page