Hi Dan, Thanks for the reply. It could possibly be the reason you have mentioned. We will set the mentioned pool properties in our environment. I was only trying to understand the pattern of this occurrence when I mentioned about sharing the pooled connection. We have followed a similar discipline as above in handling the jdbc-pool connections. Thanks again for the references as well.
Cheers! Isuruwan On Tue, Nov 12, 2013 at 8:50 PM, Daniel Mikusa <dmik...@gopivotal.com>wrote: > On Nov 12, 2013, at 4:39 AM, Isuruwan Herath <isuru...@wso2.com> wrote: > > > Hi Devs, > > > > We are using tomcat jdbc-pool v7.0.28. In one of the development > > environments we have been intermittently getting an exception from above > > interceptor. > > > > ------------------------------------------- > > > > Caused by: java.sql.SQLException: PooledConnection has already been > closed. > > This typically happens when a database connection is closed outside of the > resource pool. For example, if the connection is closed by a firewall or > the remote database. Usually adding a validation query is enough to filter > out the bad connections, but in some case you'll need to adjust the > validationInterval setting as well. > > See the config docs here. > > https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html > > > at > > > org.apache.tomcat.jdbc.pool.DisposableConnectionFacade.invoke(DisposableConnectionFacade.java:69) > > at $Proxy14.prepareStatement(Unknown Source) > > at > > > org.wso2.carbon.dataservices.core.description.query.SQLQuery.createProcessedPreparedStatement(SQLQuery.java:1367) > > > > ------------------------------------------- > > > > We are not using a very high volume and we have not set pool properties > to > > values other than the defaults. It is really difficult to recreate this > and > > I have tried running the unit tests with different numbers to pool > > configurations, but no success in reproducing above. > > > > IIUC, this occurs when connection is shared in a multi-threaded scenario. > > Possibly, one is trying to do some operation while other trying to close > it > > and return to the pool. > > You shouldn't have two threads using the same connection from the pool. > That would be an error in your program. Each thread should get it's own > connection from the pool. > > In general the pattern used by your code should be something like this. > > - Get connection from pool > - Perform work > - Return connection to pool > > You should hold the connection for a little time as possible, you should > make sure you use a proper try..catch..finally block and you should never > store or share a connection that you take from the pool. > > > Has there been any major concurrency related > > improvements done after v7.0.28? > > You can check the change logs to see what has been updated since 7.0.28. > Look at the section titled "jdbc-pool", which lists changes made to the > pool. > > https://tomcat.apache.org/tomcat-7.0-doc/changelog.html > > Dan > > > > > Really appreciate if you could give any sort of input on the cause of the > > above. > > > > Thanks and Regards! > > Isuruwan > > > > > > -- > > Isuruwan Herath > > Technical Lead > > > > Contact: +94 776 273 296 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Isuruwan Herath Technical Lead Contact: +94 776 273 296
