On Apr 8, 2005 12:39 PM, Dave Newton <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > >On Apr 8, 2005 11:28 AM, Dave Newton <[EMAIL PROTECTED]> wrote: > > > > > >>I haven't done much (anything?) with servlet listeners--what's the > >>advantage to doing it this way as opposed to a servlet.init that loads > >>on app startup? Generally what we've done is to have a thread that > >>checks a flag that signals DB changes that then calls the same code to > >>reload everything. I'm not too involved with that part of the code though. > >> > >The servlet container is *not* required to leave your load-on-startup > >servlet loaded for the entire duration of the webapp's lifetime > >(although, in practice, most containers do). For example, the > >container could unload a servlet that it sees isn't being used, or if > >it has memory contention issues, or for whatever reason is desired. > > > > > If the servlet is just putting objects into application scope does this > matter? > > We weren't using the same servlet to reload that app-scoped data (don't > ask; I don't know) but even if we were, would the only penalty be time? > IOW, the servlet isn't "gone forever," right? >
The previous servlet instance is indeed "gone forever", but anything that it has placed into servlet context attributes is still around. That being said, I have seen cases where the potential performance penalty is quite large (many seconds of database access), which will show up in one of your users waiting an abnormally long time for their response -- not something I would find very appealling. > >A ServletContextListener, on the other hand, guarantees that > >contextInitialized() will get called at startup time (before any > >requests have been processed), and contextDestroyed() will get called > >at shutdown time (after the last request), no matter what happens in > >between. > > > > > I think I'll move all this stuff over to there anyway; that sounds much > cleaner. > Yep -- it's definitely cleaner. > Thanks! > > Dave > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
