tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elli Albek <>
Subject Re: DBCP woes (running out of cursors).
Date Wed, 28 Oct 2009 22:57:18 GMT
>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.


On 10/28/09, Christopher Schultz <> wrote:
> 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
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkrodboACgkQ9CaO5/Lv0PAhGQCgooVyE8753TIz635X2lSvZJOV
> j8cAoJnX6kDBSuBscVlwjEX0kZ5SlAun
> =u9j7
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message