java - Connection behavior - DriverManager.getConnection() and DataSource.getConnection() - Stack Overflow
to customize your list.
Join the Stack Overflow Community
Stack Overflow is a community of 6.5 million programmers, just like you, helping each other.
J it only takes a minute:
If I get a connection object using DriverManager.getConnection() and DataSource.getConnection(), how they differ in behavior when .close() is called on those objects?
Before .close() method call, I got relevant Statement and ResultSet objects from these two different connections. Soon after getting these two objects, if I say connection1.close() (through DriverManager.getConnection()), it will nullify the connection object and I'm not supposed / allowed to access the relevant Statement and ResultSet objects. Correct me if I'm wrong?
Second scenario, now if I say connection2.close() (through DataSource.getConnection()), it simply returns it back to the pool. But the connection is still live. Will I be able to access the associated Statement and ResultSet objects?
17.8k84777
If we assume a (basic) DataSource (that is: one that does not do connection pooling), then you obtain a physical connection that is the same as one obtained from DriverManager (some drivers even internally use DriverManager from the DataSource, or a DataSource from DriverManager). So those connections will behave identically.
Now if we assume a DataSource that provides connection pooling, then the DataSource itself uses a ConnectionPoolDataSource (or a similar internal mechanism) to obtain a PooledConnection. This PooledConnection manages the actual physical connection to the database.
When a user requests a connection from the DataSource, the DataSource will checkout a PooledConnection, and ask it for a Connection. The PooledConnection will then create a logical connection that uses or wraps the physical connection (eg using a Proxy). The DataSource will return that logical connection to the user.
To the user the logical connection should behave identical to a physical connection in all aspects. So when a user closes the connection, that logical connection and all dependent JDBC objects will be closed and behave identical to a physical connection close.
JDBC 4.1 section 11.1 says:
Connection pooling is completely transparent to the client: A client obtains a pooled
connection and uses it just the same way it obtains and uses a non pooled connection.
And section 11.4:
If the application attempts to reuse the logical handle, the Connection implementation
throws an SQLException.
For a given PooledConnection object, only the most recently produced logical Connection object will be valid. Any previously existing Connection object is automatically closed when the associated PooledConnection.getConnection method is called.
In the background however, when the logical connection is closed, the PooledConnection will signal the DataSource that it is available for reuse, and the DataSource will then return it to the connection pool, or close the PooledConnection (which closes the physical connection) if it no longer needs the connection.
The DataSource can also forcefully revoke a connection from a user (eg when a connection is checked out too long, etc), by asking the PooledConnection to close the logical connection.
38.1k95083
connection1.close() (through DriverManager.getConnection()),
This will close the physical connection established to the database and all the resources viz. Resultset, Statement, Connection are released. So, you cannot access them after the connection is closed.
connection2.close() (through DataSource.getConnection())
This is DataSource-implementation dependent and so the behavior need not be consistent across different DataSource implementations. Also, within a given DataSource implementation, the connection's actual life cycle is dependent on various other parameters that it is strongly recommended to not differentiate this Connection from the one obtained through DriverManager.
If you really want the data held in the ResultSet to be available after the Statement and Connection are closed, you can take a look at
if that fits your usecase.
17.8k73559
The client-side caching might be dependent on the driver being used to connection not sure.
But Some drivers specifically prevent you from using a statement or resultset once the connection has been closed. Others maintain the resultset on the client side
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
rev .24602
Stack Overflow works best with JavaScript enabledDriverManagerDataSource -
- ITeye技术网站
博客分类：
某天在服务器上的网页打不开了，频繁报以下错误。
1:08:26 org.apache.tomcat.util.threads.ThreadPool logFull
严重: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status
在网上找了些回答，以下是我觉得正确的回答：
1.我想你的部分资源没有释放,积压卡死的
2.连接池问题
3.应该是服务器端响应request的线程的处理时间过长导致的
分析：
当时使用网站的人数只有2个人，不可能答到到了并发线程150的上线。所以应该不是数据库的问题。
通过对出错的提示判断，应该是连接池使用不合理造成的，或者根本没设置连接池。和数据库连接的部分是使用Spring的数据源JDBC连的，如下：
&beans&
&&& &bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"&
&&&&&&& &!-- driver for MySQL--&
&&&&&&& &property name="driverClassName"&&value&org.gjt.mm.mysql.Driver&/value&&/property&
&&&&&&& &property name="url"&&value&jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF8&/value&&/property&
&&&&&&& &property name="username"&&value&test&/value&&/property&
&&&&&&& &property name="password"&&value&test&/value&&/property&&&&&&&
问题应该出现在Spring的DriverManagerDataSource上，它负责管理这些连接的。
下边是对DriverManagerDataSource 的解释
DriverManagerDataSource in Spring Framework
&& javax.sql Interface DataSource
Implementation of SmartDataSource that configures a plain old JDBC Driver via
bean properties, and returns a new Connection every time.
Useful for test or standalone environments outside of a J2EE container, either
as a DataSource bean in a respective ApplicationContext, or in conjunction with
a simple JNDI environment. Pool-assuming Connection.close() calls will simply
close the connection, so any DataSource-aware persistence code should work.
In a J2EE container, it is recommended to use a JNDI DataSource provided by the
container. Such a DataSource can be exported as a DataSource bean in an
ApplicationContext via JndiObjectFactoryBean, for seamless switching to and from
a local DataSource bean like this class.
If you need a "real" connection pool outside of a J2EE container, consider
Apache's Jakarta Commons DBCP. Its BasicDataSource is a full connection pool
bean, supporting the same basic properties as this class plus specific settings.
It can be used as a replacement for an instance of this class just by changing
the class name of the bean definition to
"mons.dbcp.BasicDataSource".
-----------------------------------------------
Many Jakarta projects support interaction with a relational database. Creating a
new connection for each user can be time consuming (often requiring multiple
seconds of clock time), in order to perform a database transaction that might
take milliseconds. Opening a connection per user can be unfeasible in a
publicly-hosted Internet application where the number of simultaneous users can
be very large. Accordingly, developers often wish to share a "pool" of open
connections between all of the application's current users. The number of users
actually performing a request at any given time is usually a very small
percentage of the total number of active users, and during request processing is
the only time that a database connection is required. The application itself
logs into the DBMS, and handles any user account issues internally.
There are several Database Connection Pools already available, both within
Jakarta products and elsewhere. This Commons package provides an opportunity to
coordinate the efforts required to create and maintain an efficient,
feature-rich package under the ASF license.
The commons-dbcp package relies on code in the commons-pool package to provide
the underlying object pool mechanisms that it utilizes.
Applications can use the commons-dbcp component directly or through the existing
interface of their container / supporting framework. For example the Tomcat
servlet container presents a DBCP DataSource as a JNDI Datasource. James (Java
Apache Mail Enterprise Server) has integrated DBCP into the Avalon framework. A
Avalon-style datasource is created by wrapping the DBCP implementation. The
pooling logic of DBCP and the configuration found in Avalon's excalibur code is
what was needed to create an integrated reliable DataSource.
看完了解释，事实上是因为DriverManagerDataSource建立连接是只要有连接就新建一个connection,根本没有连接池的作用。改为以下开源的连接池会好点。
&bean id="myDataSource" class="mons.dbcp.BasicDataSource" destroy-method="close"&
&property name="driverClassName"&
&value&org.hsqldb.jdbcDriver&/value&
&/property&
&property name="url"&
&value&jdbc:hsqldb:hsql://localhost:9001&/value&
&/property&
&property name="username"&
&value&sa&/value&
&/property&
&property name="password"&
&value&&/value&
&/property&
测试通过，问题消除
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
被不知道谁忽悠了我很长一段时间，误认为DriverManagerDataSource这东西就是一个连接池，这下傻了
浏览: 79125 次
来自: 广州
如果字符集不一样 ，解决方案是什么 ？
function ChangeDateFormat(cellv ...
哦,你保证用的是Sql工作导出的文件,再用Sql格式导入就可以 ...
这篇文章是抄我的吧，哈哈哈
mons.dbcp.BasicDa ...C3P0属性设置和数据库连接池的获取-学网-中国IT综合门户网站-提供健康,养生,留学,移民,创业,汽车等信息
C3P0属性设置和数据库连接池的获取
来源：互联网 更新时间： 17:29:31 责任编辑：李志喜字体：
在来看WrapperConnectionPoolDataSource//WrapperConnectionPoolDataSource//获取数据源连接池 public PooledConnection getPooledConnection()
throws SQLException
return getPooledConnection((ConnectionCustomizer)null, null);
protected PooledConnection getPooledConnection(ConnectionCustomizer cc, String pdsIdt)
throws SQLException
//获取DriverManagerDataSource
nds = getNestedDataSource();
if(nds == null)
throw new SQLException("No standard DataSource has been set beneath this wrapper! [ nestedDataSource == null ]");
//委托给DriverManagerDataSource
conn = nds.getConnection();
return new NewPooledConnection(conn, connectionTester, isAutoCommitOnClose(getUser()), isForceIgnoreUnresolvedTransactions(getUser()), getPreferredTestQuery(getUser()), cc, pdsIdt);
}在来看DriverManagerDataSource//DriverManagerDataSource//获取连接 public Connection getConnection()
throws SQLException
ensureDriverLoaded();
//从驱动器，获取连接,不同的驱动返回不同的数据库连接实现
Connection out = driver().connect(jdbcUrl, properties);
if(out == null)
throw new SQLException((new StringBuilder()).append("Apparently, jdbc URL '").append(jdbcUrl).append("' is not valid for the underlying ").append("driver [").append(driver()).append("].").toString());
相关文章：
上一篇文章：下一篇文章：
最新添加资讯
24小时热门资讯
Copyright © 2004- All Rights Reserved. 学网 版权所有
京ICP备号-1 京公网安备02号ReadOnlyDriverManagerDataSource (Grails 2.1.0)
Groovy Documentation
org.codehaus.groovy.grails.plugins.datasource
[Java] Class ReadOnlyDriverManagerDataSource
java.lang.Object
org.springframework.jdbc.datasource.AbstractDataSource
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource
org.springframework.jdbc.datasource.DriverManagerDataSource
org.codehaus.groovy.grails.plugins.datasource.ReadOnlyDriverManagerDataSource
public&class ReadOnlyDriverManagerDataSource
extends org.springframework.jdbc.datasource.DriverManagerDataSource
Used for secondary datasources that are read-only and not pooled.
Authors:Burt Beckwith
protected&java.sql.Connection
(java.lang.String url, java.util.Properties props)
org.springframework.jdbc.datasource.DriverManagerDataSource#setDriverClassName(java.lang.String), org.springframework.jdbc.datasource.DriverManagerDataSource#getPassword(), org.springframework.jdbc.datasource.DriverManagerDataSource#getConnection(java.lang.String, java.lang.String), org.springframework.jdbc.datasource.DriverManagerDataSource#getConnection(), org.springframework.jdbc.datasource.DriverManagerDataSource#getUrl(), org.springframework.jdbc.datasource.DriverManagerDataSource#setUrl(java.lang.String), org.springframework.jdbc.datasource.DriverManagerDataSource#setUsername(java.lang.String), org.springframework.jdbc.datasource.DriverManagerDataSource#setPassword(java.lang.String), org.springframework.jdbc.datasource.DriverManagerDataSource#getUsername(), org.springframework.jdbc.datasource.DriverManagerDataSource#setConnectionProperties(java.util.Properties), org.springframework.jdbc.datasource.DriverManagerDataSource#getConnectionProperties(), org.springframework.jdbc.datasource.DriverManagerDataSource#unwrap(java.lang.Class), org.springframework.jdbc.datasource.DriverManagerDataSource#isWrapperFor(java.lang.Class), org.springframework.jdbc.datasource.DriverManagerDataSource#getLogWriter(), org.springframework.jdbc.datasource.DriverManagerDataSource#getLoginTimeout(), org.springframework.jdbc.datasource.DriverManagerDataSource#setLoginTimeout(int), org.springframework.jdbc.datasource.DriverManagerDataSource#setLogWriter(java.io.PrintWriter), org.springframework.jdbc.datasource.DriverManagerDataSource#getParentLogger(), org.springframework.jdbc.datasource.DriverManagerDataSource#wait(), org.springframework.jdbc.datasource.DriverManagerDataSource#wait(long), org.springframework.jdbc.datasource.DriverManagerDataSource#wait(long, int), org.springframework.jdbc.datasource.DriverManagerDataSource#equals(java.lang.Object), org.springframework.jdbc.datasource.DriverManagerDataSource#toString(), org.springframework.jdbc.datasource.DriverManagerDataSource#hashCode(), org.springframework.jdbc.datasource.DriverManagerDataSource#getClass(), org.springframework.jdbc.datasource.DriverManagerDataSource#notify(), org.springframework.jdbc.datasource.DriverManagerDataSource#notifyAll()
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getPassword(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getConnection(java.lang.String, java.lang.String), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getConnection(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getUrl(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#setUrl(java.lang.String), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#setUsername(java.lang.String), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#setPassword(java.lang.String), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getUsername(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#setConnectionProperties(java.util.Properties), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getConnectionProperties(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#unwrap(java.lang.Class), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#isWrapperFor(java.lang.Class), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getLogWriter(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getLoginTimeout(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#setLoginTimeout(int), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#setLogWriter(java.io.PrintWriter), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getParentLogger(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#wait(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#wait(long), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#wait(long, int), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#equals(java.lang.Object), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#toString(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#hashCode(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#getClass(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#notify(), org.springframework.jdbc.datasource.AbstractDriverBasedDataSource#notifyAll()
getConnectionFromDriverManager
protected&java.sql.Connection getConnectionFromDriverManager(java.lang.String url, java.util.Properties props)
Groovy Documentation}