You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Isuruwan Herath <is...@wso2.com> on 2013/11/12 10:39:10 UTC
[jdbc-pool] Exception while using DisposableConnectionFacade interceptor
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.
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. Has there been any major concurrency related
improvements done after v7.0.28?
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
Re: [jdbc-pool] Exception while using DisposableConnectionFacade interceptor
Posted by Isuruwan Herath <is...@wso2.com>.
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 <dm...@gopivotal.com>wrote:
> On Nov 12, 2013, at 4:39 AM, Isuruwan Herath <is...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Isuruwan Herath
Technical Lead
Contact: +94 776 273 296
Re: [jdbc-pool] Exception while using DisposableConnectionFacade interceptor
Posted by Daniel Mikusa <dm...@gopivotal.com>.
On Nov 12, 2013, at 4:39 AM, Isuruwan Herath <is...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org