[
https://issues.apache.org/jira/browse/DBCP-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Brachet updated DBCP-328:
------------------------------
Description:
2 problems in one but they are very related:
# When the database is down (the actual server/machine, not the MySQL instance)
the JDBC driver will wait {{connectTimeout}} before timing out.
{{BasicDataSource.createDataSource()}}, which calls
{{validateConnectionFactory()}} when it initializes, is synchronized. So each
threads are waiting on the synchronize lock so they can all then wait
{{connectTimeout}} before finally timing out.
Imagine a 5sec {{connectTimeout}} and 10 concurrent theads, the last thread
will timeout after roughly 50 seconds.
# Similarly when the database dies (again the actual server/machine, not the
instance), after {{BasicDataSource}} has initialized, the JDBC driver will
again wait {{connectTimeout}} before timing out when new connections are
created to grown the pool. {{PoolableConnectionFactory#makeObject()}}, which
calls {{createConnection()}}, is also synchronized causing the same exponential
wait for any threads requesting a connection from the pool.
Maybe I should explain that Connector/J closes the actual connection when it
detects a communication failure with the database, and the connection is then
removed from the pool. So when the database server dies the pool gets depleted
and new connections need to be created.
I am not sure how to address #1 but #2 can be addressed by calling
{{createConnection()}} outside of any locks.
For example:
{noformat}
public Object makeObject() throws Exception {
ConnectionFactory connFactory;
KeyedObjectPoolFactory stmtPoolFactory;
ObjectPool pool;
synchronized (this) {
connFactory = _connFactory;
stmtPoolFactory = _stmtPoolFactory;
pool = _pool;
}
Connection conn = connFactory.createConnection();
if(null != stmtPoolFactory) {
KeyedObjectPool stmtpool = stmtPoolFactory.createPool();
conn = new PoolingConnection(conn,stmtpool);
stmtpool.setFactory((PoolingConnection)conn);
}
return new PoolableConnection(conn,pool,_config);
}
{noformat}
Although there may be some problem if the pool is swapped while creating a
connection...
See also dbcp-300.
was:
2 problems in one but they are very related:
1- When the database is down (the actual server/machine, not the MySQL
instance) the JDBC driver will wait connectTimeout before timing out.
BasicDataSource.createDataSource(), which calls validateConnectionFactory()
when it initializes, is synchronized. So each threads are waiting on the
synchronize lock so they can all then wait connectTimeout before finally timing
out.
Imagine a 5sec connectTimeout and 10 concurrent theads, the last thread will
timeout after roughly 50 seconds.
2- Similarly when the database dies (again the actual server/machine, not the
instance), after BasicDataSource has initialized, the JDBC driver will again
wait connectTimeout before timing out when new connections are created to grown
the pool. PoolableConnectionFactory#makeObject(), which calls
createConnection(), is also synchronized causing the same exponential wait for
any threads requesting a connection from the pool.
Maybe I should explain that Connector/J closes the actual connection when it
detects a communication failure with the database, and the connection is then
removed from the pool. So when the database server dies the pool gets depleted
and new connections need to be created.
I am not sure how to address #1 but #2 can be addressed by calling
createConnection() outside of any locks.
For example:
{noformat}
public Object makeObject() throws Exception {
ConnectionFactory connFactory;
KeyedObjectPoolFactory stmtPoolFactory;
ObjectPool pool;
synchronized (this) {
connFactory = _connFactory;
stmtPoolFactory = _stmtPoolFactory;
pool = _pool;
}
Connection conn = connFactory.createConnection();
if(null != stmtPoolFactory) {
KeyedObjectPool stmtpool = stmtPoolFactory.createPool();
conn = new PoolingConnection(conn,stmtpool);
stmtpool.setFactory((PoolingConnection)conn);
}
return new PoolableConnection(conn,pool,_config);
}
{noformat}
Although there may be some problem if the pool is swapped while creating a
connection...
See also dbcp-300.
> exponential wait when requesting connections while the database is down
> -----------------------------------------------------------------------
>
> Key: DBCP-328
> URL: https://issues.apache.org/jira/browse/DBCP-328
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2.2
> Environment: Tomcat Apache 5.5.28
> MySQL 5.1 / Connector/J 5.1.5
> JDK 1.5.0_22
> Reporter: Nick Brachet
>
> 2 problems in one but they are very related:
> # When the database is down (the actual server/machine, not the MySQL
> instance) the JDBC driver will wait {{connectTimeout}} before timing out.
> {{BasicDataSource.createDataSource()}}, which calls
> {{validateConnectionFactory()}} when it initializes, is synchronized. So each
> threads are waiting on the synchronize lock so they can all then wait
> {{connectTimeout}} before finally timing out.
> Imagine a 5sec {{connectTimeout}} and 10 concurrent theads, the last thread
> will timeout after roughly 50 seconds.
> # Similarly when the database dies (again the actual server/machine, not the
> instance), after {{BasicDataSource}} has initialized, the JDBC driver will
> again wait {{connectTimeout}} before timing out when new connections are
> created to grown the pool. {{PoolableConnectionFactory#makeObject()}}, which
> calls {{createConnection()}}, is also synchronized causing the same
> exponential wait for any threads requesting a connection from the pool.
> Maybe I should explain that Connector/J closes the actual connection when it
> detects a communication failure with the database, and the connection is then
> removed from the pool. So when the database server dies the pool gets
> depleted and new connections need to be created.
> I am not sure how to address #1 but #2 can be addressed by calling
> {{createConnection()}} outside of any locks.
> For example:
> {noformat}
> public Object makeObject() throws Exception {
> ConnectionFactory connFactory;
> KeyedObjectPoolFactory stmtPoolFactory;
> ObjectPool pool;
> synchronized (this) {
> connFactory = _connFactory;
> stmtPoolFactory = _stmtPoolFactory;
> pool = _pool;
> }
> Connection conn = connFactory.createConnection();
> if(null != stmtPoolFactory) {
> KeyedObjectPool stmtpool = stmtPoolFactory.createPool();
> conn = new PoolingConnection(conn,stmtpool);
> stmtpool.setFactory((PoolingConnection)conn);
> }
> return new PoolableConnection(conn,pool,_config);
> }
> {noformat}
> Although there may be some problem if the pool is swapped while creating a
> connection...
> See also dbcp-300.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
