Recently one of our legacy applications was changed from a non-pooling data source to one that pools. Immediately connection leaks started. This made me realize that Java was garbage collecting the unclosed connections when the non-pooling data source was being used. With the pool calling close() on a connection was required to move it back to the pool. If close() was not called the connection was leaked, i.e. never usable again but also never garbage collected.
This has me asking myself what is a connection in physical terms? Is a connection just an object so a connection leak is a memory leak? Or does a connection encapsulate some other finite resource that can be used up faster than available memory can be used up.
I've been using Connection for years and never really thought about this.
Originally posted by William Stafford: ...Is a connection just an object so a connection leak is a memory leak? Or does a connection encapsulate some other finite resource that can be used up faster than available memory can be used up....
It holds finite resources: an active connection to the database. These objects consume resources on client side (in your connection pool), but also in the database server. PMD can help you to find situations where you don't close a connection.
I would like to add something on similar notes. If you use datasource.xml file you need to define minimum number (5 for exp) of connections and maximum number (25 for exp) of connections. The moment you start your app server, it makes 5 physical connection originating from the machine where app server is running. I have had my DBA calling me about persistant connections and asking me why do I have those connection open all the time.
It also plays a tricky licensing issues. You can have just 5 Oracle licenses and you can make a web app where 50 users are using those 5 connections through web app. My 2 cents.