DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37262>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37262 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-27 23:51 ------- (In reply to comment #9) > Glen, of course I close my connections. But the datasource uses a connection > pool and the underlying JDBC connection in not really closed but just returned > to the pool. I know -- SRV10.2.2 was just a "for example" -- it implies the types of things the Developer can/should do, such as create a listener to close the DBCP when the webapp is shut down. However, I can't see how this would be doable within Tomcat, given that the object is created within server.xml. The Developer does not have access to the Java object external to the Tomcat source code; they have to recode Tomcat as you've done here. > It is the responsibility of the container who manages the > datasource to call close() (on the datasource, not the connection) when the > context is stopped. Well, this seems to be too specific--the Servlet 2.4 spec doesn't mention data sources and close() methods specifically. So I'm not so certain how much of a container requirement this is. > > Part of the problem is that javax.sql.DataSource does not provide a close() > method, only the DBCP DataSource does. But this makes sense to me, because > javax.sql.DataSource is an interface for the users, and the appserver should > use > its own means to cleanup the datasource. If that were the case, I think there would have to be a standard definition for a data source, as well as a "close()" method that it must implement within the Servlet spec. > The users should not be able to close a > datasource, because it is meant to be managed by the appserver. OK--but what if a datasource is shared by multiple applications/instances of Tomcat, etc.? (possible?) Then we wouldn't want it to be closed automatically whenever a webapp is shut down. > > Here is a quote from the JDBC 3.0 spec the mentions that an appserver > implementation closes a datasource. > > "A connection pool manager shuts down a physical connection by calling the > method PooledConnection.close. This method is typically called only in > certain circumstances: when the application server is undergoing an orderly > shutdown, when the connection cache is being reinitialized, or when the > application server receives an event indicating that an unrecoverable error > has > occurred on the connection." > But this doesn't seem to rule out that the developer won't be creating an application event listener that is activated to specifically shut down the data source (data source API's vary, so I don't see how the app server can do this in a common manner for all data sources.) But again, I don't see how this is doable within Tomcat in an server.xml-created connection pool. > The connection manager is DBCP but it has no way of knowing that the tomcat > context is stopped. That's why, for a proper integration there needs to be > some > glueing code that listens to tomcat lifecycle events and notifies DBCP. It > doesn't strictly belong to Tomcat, it doesn't strictly belong to DBCP, so > that's > why it does not exist. I think there are two problems here (again, newbie speaking here): 1.) The application developer does not have programmatic access to the connection pool created in server.xml, so he/she cannot call close() on it from a developer-created application event listener even if he/she wanted to. (Your opinion is that this should not need to be done anyway, it should be automatic.) 2.) Tomcat integrates DBCP enough to allow for creation of a connection pool from server.xml, but is not calling close() on those connection pools after the webapp is shut down. I don't have an opinion either way on this; I'm just trying to understand the issue, although I wonder if other users have complained about this as well, and if not, why not. Glen -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
