Hi, >From what I can remember, which has been a long time ago, requests are being handled by servlets after the shutdown process has started and the pool was closed. I would imagine that this is a violation of the spec as well, but I am not sure. You would imagine that JNDI resources should be available for the web app until it is closed, as well as during the shutdown process. Context listeners should be able to access the pool via JNDI even during shutdown.
The problem with "about to be shut down" is that it is not fully shut down. It is not shut down at least in the sense that the context listener is running. There may be another listener that tries to use the database for flushing asynch writes. So I rather keep connection management outside of the app. Thats why the tomcat listener seems like a better choice, especially when there is a dedicated event for after stop. >From the testing, after stop is truly the last event in the chain and runs after the web app is completely shut down and all its internal listeners are called. In other words, objects that are started outside the app should not be shut in from within the app if possible. The web app should only stop what it starts by itself. E On 10/28/09, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Elli, > > On 10/28/2009 12:21 AM, Elli Albek wrote: >> In terms of listeners, I saw that Tomcat executes requests while in >> the closing process. > > That's a problem. What kind of listener are you using? > >>> My understanding was that: >>> >>> 1. Tomcat does not remove the connection pool >>> 2. Once the shutdown process has started, no new requests will be >>> handled by the currently-shutting-down context >>> >>> Could these two items give the result you are observing? It's easy >>> enough to have your webapp close the DataSource (even though it's kinda >>> stupid that Tomcat doesn't do it for you). >> >> That depends on which shutdown it is. Understanding 2 is not correct >> from my debugging. You can have a sequence of: >> 1. Connection pool closed >> 2. Request sent to servlet > > The documentation for ServletContextListener.contextDestroyed says: > > " > Notification that the servlet context is about to be shut down. All > servlets and filters have been destroy()ed before any > ServletContextListeners are notified of context destruction. > " > > Assuming that servlets aren't being re-initialized to service new > requests, using a ServletContextListener ought to work in this case. I'm > happy to hear an explanation for why my assumption isn't true, but this > woul dbe my expectation. If your webapp is handling requests after the > ServletContextListener.contextDestroyed method is called, I would > consider that a violation of the servlet specification. > >> If you want to add a listener that closes the pool, I would try >> adding tomcat lifecycle listener to the context. You can handle >> event Lifecycle.AFTER_STOP_EVENT. Try both listeners (web app and >> tomcat) and see which one runs last, and put the code there. > > I'm guessing that Tomcat's listener would execute after the > ServletContextListener, since AFTER_STOP_EVENT indicates that the stop > has occurred, while the servlet-API listener says it "is about to be > shut down". > >> Then the vision of J2EE designers of "separation of roles" >> materializes :) > > Something tells me those guys didn't exactly invent the concept of > separation of roles. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrodboACgkQ9CaO5/Lv0PAhGQCgooVyE8753TIz635X2lSvZJOV > j8cAoJnX6kDBSuBscVlwjEX0kZ5SlAun > =u9j7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
