[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959716#comment-13959716
]
Davide Caroselli edited comment on DBCP-412 at 4/4/14 7:32 AM:
---------------------------------------------------------------
Ok, I've modified the code but I found another issue (maybe). This is the
example:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
// = EDITED ==============
for (int i = 0; i < 100; i++)
try {
connection = dataSource.getConnection();
System.out.println(connection.hashCode());
statement = connection.prepareStatement("SELECT 1");
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPool<PoolableConnection> connectionPool = new
GenericObjectPool<>(poolableConnectionFactory);
// = EDITED ==============
connectionPool.setMaxTotal(1);
poolableConnectionFactory.setPool(connectionPool);
PoolingDataSource<PoolableConnection> dataSource = new
PoolingDataSource<>(connectionPool);
return dataSource;
}
{code}
Now the code does not throw exceptions anymore, but it returns always a new
connection.
I request 100 times, but every time the connection hashcode is different; I've
made a similar example but with DBCP v1.4 over Common Pool 1.6 and with these
jars the hashcode is always the same.
Is this normal or does it really create new connection anytime?
was (Author: davidecaroselli):
Ok, I've modified the code but I found another issue (maybe). This is the
example:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
// = EDITED ==============
for (int i = 0; i < 100; i++)
try {
connection = dataSource.getConnection();
System.out.println(connection.hashCode());
statement = connection.prepareStatement("SELECT 1");
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPool<PoolableConnection> connectionPool = new
GenericObjectPool<>(poolableConnectionFactory);
// = EDITED ==============
connectionPool.setMaxTotal(1);
poolableConnectionFactory.setPool(connectionPool);
PoolingDataSource<PoolableConnection> dataSource = new
PoolingDataSource<>(connectionPool);
return dataSource;
}
{code}
Now the code does not throw exceptions anymore, but it returns always a new
connection.
I request 100 times, but every time the connection hashcode is different; I've
made a similar example but with DBCP v1.4 over Common Pool 1.6 and with these
jars the hashcode is always the same.
Is this normal or it really create new connection anytime?
> dbcp2.PoolableConnection.close raises NullPointerException
> ----------------------------------------------------------
>
> Key: DBCP-412
> URL: https://issues.apache.org/jira/browse/DBCP-412
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: Mac OSX, Java 7, SQLAzure
> Reporter: Davide Caroselli
> Priority: Critical
> Labels: NullPointerException, PoolableConnection
>
> I found a critical error while closing a PoolableConnection.
> Here's the code to reproduce the bug (largely copied from the example shown
> in the Apache DBCP site):
> {code:title=PoolingDataSourceExample2.java|borderStyle=solid}
> public static void main(String[] args) throws Throwable {
> Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
> DataSource dataSource = setupDataSource(jdbcUrl);
> Connection connection = null;
> PreparedStatement statement = null;
> ResultSet result = null;
> try {
> connection = dataSource.getConnection();
> statement = connection.prepareStatement("SELECT 1");
> result = statement.executeQuery();
> } finally {
> result.close();
> statement.close();
> connection.close();
> }
> }
> public static DataSource setupDataSource(String connectURI) {
> ConnectionFactory connectionFactory = new
> DriverManagerConnectionFactory(connectURI, null);
> PoolableConnectionFactory poolableConnectionFactory = new
> PoolableConnectionFactory(connectionFactory, null);
> ObjectPool<PoolableConnection> connectionPool = new
> GenericObjectPool<>(poolableConnectionFactory);
> PoolingDataSource<PoolableConnection> dataSource = new
> PoolingDataSource<>(connectionPool);
> return dataSource;
> }
> {code}
> When the code tries to close the connection (in the final block), an
> exception is raised:
> {code:title=PoolingDataSourceExample2.java|borderStyle=solid}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
> at
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
> at
> org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
> at
> org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
> at
> dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
> at
> dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
> As I can see, the problem is the "_pool" variable inside PoolableConnection
> but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
