与数据库连接释放有关的设计模式

使用Java做过商业应用开发的人想必一定用到过数据库。

不论具体方案是使用JDBC还是JDO还是直接使用J2EE提供的连接池又或者是使用Hibernate屏蔽了这一切,不变的原则是,数据库连接是有限的资源,为了实现数据持久化的高效和稳定,不应该不加控制地频繁创建数据库连接;更不能在建立连接(或从连接池中取出)并使用之后就简单地结束,而不做资源回收。即使这种资源有超时空闲的自动回收机制,这种做法也是不可接受的。

打住,随便发了点儿评论。言归正传,本文的标题虽然是讨论数据库连接释放的问题,但实质是借着这个话题说明一下设计模式在Java中的应用。

现在,让我们设想一个虚拟场景:当前项目的数据库连接方式采用了JDBC + 连接池。如此设想是因为大概这种实现的效率最高,且可以发挥的地方也最多。

系统启动阶段建立了数据库的连接池,里面预先放了很多的连接,供需要持久化的模块调用,并接收返还的连接。

这里,每块借用了连接的代码都要记得用完了之后一定得返还连接。否则,连接池里的连接用完了,系统就不得不新建连接,迟早会抛出连接无法创建的异常。

那么,第一种方案是,把所有的数据库操作放在一个try块里。然后在finally里执行返还连接的操作。这种方案好处是便于实现,目的单纯。对于只有一、两处数据库操作的应用来说,效果明显,维护起来也不困难。

但是假设应用中不只含有一个数据库,比如说是按照功能划分了安全管理、商品库存、销售记录、员工考勤等库(表空间),而实际上会用到数据操作的不下几十处,那么第一种方案就是有问题的了。尤其对于一次访问若干个库,比如说同时访问商品库存和销售记录,同时访问安全管理和员工考勤,这时候程序员要时刻牢记目前有哪些连接在使用,finally要释放哪些连接,即使项目完成了,也不可能通过某种便捷有效的手段保证所有的连接都能够正常释放。举个最简单的例子。

// ...
Connection connA = DbUtil.getConnA();
Connection connB = DbUtil.getConnB();

try {
// ...
} catch (Exception ex) {
// ...
} finally {
connA.close();
connB.close();
}

粗看上去,似乎两个连接都释放掉了。但实际并非如此,connB不一定会被关掉。假设在try块中,connA的服务器突然宕机了。这时候,在finally块里,connA.close();将会抛出异常,connB.close();的代码将不会被执行。

这时候内行说话了,只要在finally块中给每个close()方法套上try块就行了,像这样:

// ...
} finally {
try {
connA.close();
} catch (Exception ex) {
}
try {
connB.close();
} catch (Exception ex) {
}
}
}

这样改是没有毛病了,不过稍微有些冗长。再修改一下:

// ...
} finally {
DbUtil.close(connA);
DbUtil.close(connB);
}
}
// ...
public final class DbUtil
{
private DbUtil()
{
}

public static void close(Connection conn)
{
try {
conn.close();
} catch (Exception ex) {
}
}
}

那么如何保证几十个用到连接的地方都释放了呢?尤其C+P之后,编译通过也不说明逻辑没有问题。例如:

// ...
} finally {
DbUtil.close(connA);
DbUtil.close(connA); // C + P 后遗症,忘记修改变量名了
}
}
// ...

用了什么就要记住释放什么,这种事,一点儿安全感都没有。

那么,现在要隆重祭出设计模式这杆大旗了。

不过很不好意思地说,具体是什么模式,实际上我心里也没底。我先解释解释吧。

首先,设计目的是,要能够比较自由地使用某种资源,并且在停止使用资源之后必然做到自动的资源释放。

其次,设计思想是,把使用资源的这个操作变为整个操作中可以被替换的部分,整个流程应该是这样的:取得资源,使用资源,释放资源。其中使用资源是不断变化的,相应取得资源也有可能发生变化,但是释放资源不会有变化,而且这样的三步走流程也始终保持不变。

因此,我们可以设想有一个对象,创建的时候把资源和资源操作当作参数注入其中,然后执行三步走。这样,只要所有的数据库操作都使用这个对象来执行,我们就可以很确信的说,所有的资源必然都会被正确的释放。除非我们设计的对象有什么其他缺陷。不过这样的方案肯定能大大简化代码的维护,把散布在各处的数据持久化操作的维护转移到对某个类的维护。

由于Java没有闭包,因此只能使用对象模仿函数指针。代码如下:

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

/**
* DbAdapter
* 数据库访问接口类
*/
public abstract class DbAdapter
{
/**
* 处理sql,并根据要求执行数据操作或查询
*/
static Object process(Connection conn, String sql, DbParamInjector injector, DbReader reader) throws SQLException
{
PreparedStatement pstmt = null;
ResultSet rs = null;
try {
pstmt = conn.prepareStatement(sql);
if (injector != null) {
if (reader != null) {
injector.setParams(pstmt);
rs = pstmt.executeQuery();
return reader.read(rs);
} else {
do {
injector.setParams(pstmt);
pstmt.execute();
} while (injector.hasNext());
return null;
}
} else {
if (reader != null) {
rs = pstmt.executeQuery();
return reader.read(rs);
} else {
pstmt.execute();
return null;
}
}
} finally {
// 释放数据库资源
DBUtil.close(conn, pstmt, rs);
}
}
}

/**
* DbParamInjector
* PreparedStatement的参数注入器
*/
abstract class DbParamInjector
{
abstract void setParams(PreparedStatement pstmt) throws SQLException;

/**
* 是否还有下一条待执行的数据操作,重载的时候要注意避免死循环
*/
boolean hasNext()
{
return false;
}
}

/**
* DbReader
* 数据结果集的读取器
*/
interface DbReader
{
Object read(ResultSet rs) throws SQLException;
}

使用例子如下:

// ...
String sql = "INSERT INTO TBL_USERLOG (LOGID, USERID, LOGDATE, LOGNOTE)"
+" VALUES (?, ?, ?, ?)";
DbParamInjector injector = new DbParamInjector() {

public void setParams(PreparedStatement pstmt) throws SQLException
{
int i = 1;
pstmt.setInt(i++, logId);
pstmt.setInt(i++, userId);
pstmt.setTimestamp(i++, new Timestamp(new Date().getTime()));
pstmt.setString(i++, new logNote);
}
};
try {
DbAdapter.process(conn, sql, injector, null);
} catch (SQLException ex) {
ex.printStackTrace();
}
// ...


当然,以上的代码只是符合某种数据库访问的需要,并不是普遍适用的例子。对于需要一边读入数据,一边更新表或者其它更为复杂模式的数据库使用,还是需要进一步改动作为引入参数的函数对象的设计和实现方式。这里就不进一步展开了。

OK,最后说一下我对其中有关的一些设计模式的理解。

首先,所谓命令模式,就是:
[list]
[*]我接编程项目,这是一个抽象概念。
[*]所有的编程项目都是一样的需求文档格式,一样的产品输出介质,这是统一的接口。
[*]你需要实现一个Java项目,这是一个具体的请求。
[*]于是,我雇了一个小伙计,帮你把项目做了。你把钱给我。这是一个用例。
[/list]
如此,虽然我对外接收编程项目,但实质工作不是我做的,我把工作转嫁给别人去做。
我只不过规范了编程人员的需求输入和产品输出。并通过这个接口派发项目。
至于编程人员怎么开发,我也不知道。

我们的例子中,小伙计使用的需求文档格式就是DbParamInjector,如果有输出的话,处理输出的就是DbReader。

其次,所谓工厂模式,就是:
[list]
[*]咖啡厂制造罐装咖啡。
[*]一罐咖啡包含咖啡粉、植脂末、糖、添加剂、瓶子,包装纸。
[*]装瓶的流程是确定的,原料还没到。
[*]一旦原料定下来了,咖啡的风味就定了。
[*]那么就先安排好工位,大家排排坐。
[*]原料来了,一罐罐咖啡也出来了。
[/list]

而我们的例子里面,就多了最后一步,把用剩下的咖啡粉扫扫起来,倒入原料池。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值