基于J2EE平台的应用开发中,大多数的应用都需要跟数据库打交道。而自从接触JDBC起,我们便不止一次地被告之:数据库资源是十分宝贵的系统资源,一定要谨慎使用。但令人遗憾的是,在笔者见过的大部分跟数据库相关的应用开发中,针对数据库资源的使用总是充斥着这样或者那样的问题。在本文中,笔者对一些常见的错误或者不当的使用数据库资源的案例进行介绍与分析,帮助读者避免某些错误的发生。
未正确关闭数据库连接
自增长整数型字段赋值表
申请了数据库连接,却没有及时关闭,这是最常见的数据库连接使用方面的错误。犯这种错误的原因很多,以下是常见的一种比较低级的错误:
public void foo() {
Connection conn=
getConnection();
Statement stmt = null;
try {
conn=getConnection();
stmt=conn.createStatement();
} catch(Exception e) {
} finally {
close(stmt, conn);
}
}
在上述案例中的第2行代码中,作者申请了一个Connection,但在第6行代码中,又申请了一个新的,并且丢失了第一次申请的Connection的引用。至此,当程序每调一次Foo方法,将导致申请一个新的Connection而没有释放它。因此,当数据库达到最大连接数时,将导致整个应用的运行失败。
避免这种错误的方法有很多,譬如,可采用类似于FindBugs的代码分析工具对应用的源码进行分析,找出可能产生错误的代码。
此外,在应用中,我们要频繁地对申请的数据库连接进行关闭与释放。此时,建议封装成某些工具类使用,并且要尽可能安全地关闭数据库连接。
任意申请数据库连接
不考虑事务上下文,任意申请数据库连接资源也是常见的不当用法。但这种问题往往是难以克服的,根源在于Java是一种面向对象的语言,而数据库的事务却是一种批量化的操作过程。我们以常见的序列号的实现方案为例:在某些应用场景中,我们需要一种自增长的整数型字段。但由于不同的数据库有不同的实现,所以,为达到各个数据库兼容的目的,我们常用的解决方案是,新建一张T_SEQUENCE表,它可能包含的字段有:NAME varchar(100), CURRENT_VAL number(10);其中,NAME存放序列的名称,而CURRENT_VAL存放序列的当前值。假设某一业务对象Customer需要新增一笔记录时,为获得不重复且自增长的Customer ID,需要将T_SEQUENCE表中与该业务表对应的序列号加1并更新,然后将更新后的值作为Customer的ID。我们以面向对象的3种方法来实现:
public class Customer {
/更新序列号使其加1/
public void sequencePlus(){
Connection conn=null;
Statement stmt =null;
……//将T_SEQUENCE的序列号当前值加1;
}
/获取当前序列号/
public int getSequenceCurrentVal(){
Connection conn=null;
Statement stmt=null;
ResultSet rset =null;
……// 获取当前的序列号值;
}
/新增一条Customer记录,自动根据序列号生成主键/
public void addCustomer(String name) {
Connection conn=null;
PreparedStatement stmt = null;
ResultSet rset=null;
sequencePlus();// 序列号加1;
int id = getSequenceCurrentVal(); // 得到当前序列号;
…….// 将最新序列号作为新的T_Customer记录的主键插入;
}
}
针对这种应用场景,我们首先需要认识到:上述3个方法应该属于同一个数据库事务。否则,在并发情况下,将出现由于主键重复而导致数据插入失败的情况。但同时,我们也需要看到:即便上述3个方法的执行位于同一个事务中,但3个方法使用的是不同的数据库连接,虽然在sequencePlus方法中将T_SEQUENCE表中的数据加1 ,但在事务并未提交的情况下,由于Connection隔离级别的原因,在getSequenceCurrentVal方法中,是看不到sequencePlus方法中更新以后的数据的。这样,也将导致数据插入失败,因为主键势必跟旧有ID值重复。
因此,传统编程方法为克服上述问题,只有在上述的方法中使用同一个Connection,才能够保证业务数据的正确。
中国足彩网信息请查看IT技术专栏