commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Brachet (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DBCP-328) exponential wait when requesting connections while the database is down
Date Fri, 26 Mar 2010 15:00:28 GMT

     [ 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:

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.

  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:

    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);
    }

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:
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message