使用 c3p0 的话,也是 java.sql.Connection,只要是 JDBC 都是这个接口的对象!
使用完后必须 con.close() 掉 ,使用连接池的话,执行 con.close 并不会关闭与数据库的 TCP 连接,而是将连接还回到池中去,如果不 close 掉的话,这个连接将会一直被占用,直接连接池中的连接耗尽为止。
至于是如何做到 con.close 并不是真正意义上的关闭连接?而是直接将连接还回到池中去?
一般有两种方式:
一:使用装饰器模式,在装饰器构造中传入一个真正的 Connection,这个装饰器实现 Connection,使用构造 传入 Connection 委托重写所有方法,并改写 close 方法:
然后经过连接池控制的 Connection 对象都使用该装饰器进行包装
二:动态代理:
使用动态代理重新实现 close 方法,每个获得 Connection 是一个代理后的对象。
一个完善的连接池,其架构设计非常复杂,Connection#close 问题就是连接池诸多设计难点当中的一个。
使用完后必须 con.close() 掉 ,使用连接池的话,执行 con.close 并不会关闭与数据库的 TCP 连接,而是将连接还回到池中去,如果不 close 掉的话,这个连接将会一直被占用,直接连接池中的连接耗尽为止。
至于是如何做到 con.close 并不是真正意义上的关闭连接?而是直接将连接还回到池中去?
一般有两种方式:
一:使用装饰器模式,在装饰器构造中传入一个真正的 Connection,这个装饰器实现 Connection,使用构造 传入 Connection 委托重写所有方法,并改写 close 方法:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
public
class
ConnectionDecorator
implements
Connection {
private
Connection con =
null
;
public
ConnectionDecorator(Connection con) {
this
.con = con;
}
public
void
close()
throws
SQLException {
// 重写!
}
public
void
commit()
throws
SQLException {
this
.con.commit();
}
public
Statement createStatement()
throws
SQLException {
return
this
.con.createStatement();
}
public
Statement createStatement(
int
resultSetType,
int
resultSetConcurrency)
throws
SQLException {
return
this
.con.createStatement(resultSetType, resultSetConcurrency);
}
......
}
|
然后经过连接池控制的 Connection 对象都使用该装饰器进行包装
二:动态代理:
使用动态代理重新实现 close 方法,每个获得 Connection 是一个代理后的对象。
一个完善的连接池,其架构设计非常复杂,Connection#close 问题就是连接池诸多设计难点当中的一个。