On 20.11.2013, at 14:21, Christopher Schultz <ch...@christopherschultz.net> wrote:
> Rainer, > FWIW, Connection.close also states this: > > " > Releases this Connection object's database and JDBC resources > immediately instead of waiting for them to be automatically released. > " > > Does that mean that all connection pools by design are in direct > violation of the JDBC spec? I assume you’re referring to the "Releases this Connection object's database resources” part, then yes, they’re in violation of the letter of the API spec. I’m not sure whether the Javadoc is regarded as binding as the spec document though. And following the letter would indeed defy the very purpose of the pool. The other pools that I know do free the JDBC resources though. And that’s the part of the behavior that is really visible to the application. (And yes, Javadoc says it is best practice to explicitly close the JDBC resources as early as possible, but it also states that one can get away with not doing so). I also think that this is a justifiable spec violation, and all I’m asking is that this fact is shown more prominently, esp. as JDBC pool is advertised as a drop-in replacement for DBCP. Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
