62,614
社区成员
发帖
与我相关
我的任务
分享
DbSource dbSource = XmlConfig.getDbSource("test");
Connection con = dbSource.getConnection();
try {
DbUnifier unifier = new DbUnifier(con);
RowSet rowSet = unifier.executeSelectSql("select * from AAA order by A", 100, 50);
} finally {
DbUtil.closeConnection(con);
}
} finally {
if (this.con == null) {
DbUtil.closeConnection(con);
}
}
这代码要仔细看,判断的是全局的con,是由第三方传入的,而不是方法内自己创建的con,这里实际上是判断是否第三方传入了con,如果传入的不用管它,否则就关闭自己创建的con,没有con无法关闭的问题。
3、close方法都会抛SQLException,但是抛出后一般也是无法处理的,我们索性就不予处理这样的情况,捕获后直接转换成RuntimeException,无需再烦琐的写处理Exception的代码。另一个好处是在Spring的使用过程中,通过直接抛出RuntimeException可以直接对事务进行回滚,非常方便,无额外代码。
4、这个纯属书写习惯问题,应该是不影响效率,可以考虑改一下
5、我写了十几年的jdbc代码了,这个getObject我还是经常用的,但这个方法并不可靠的,一些对象并不能通过getObject获得,还有一些类型,不同数据库转出来的Object并不一致,这个对代码移植都是有害的,所以尽量避免使用这个方法。
6、totalRowCount与size()的值含义并不相同啊,做过分页的人都知道totalRowCount指的是所有记录的总数,size()获得的只是当前页的记录数
请测一下getSequenceNextValue方法,此方法用表模拟序列是为了各数据库移植的问题,并且在算法中加入了乐观锁机制处理,完全可以保证多线程或者集群的情况下无重值,无跳号,准确无误。
另外提到的连接问题,如果是一般的使用方式,反复与数据库建立连接、关闭连接,性能一定比较差。但是一般我们都会用连接池,用ThreadLocal绑定事务,在这样的环境下,这完全不是个问题。rowSet.setTotalRowCount(rowSet.size());
为什么RowSet的totalRowCount属性不是只读且自动与size或者说addRow方法绑定的。
也就是说
public int getTotalRowCount() {
return size();
} // 并且去掉set方法
DbUtil.closeConnection(con);
前面的逻辑判断吧!!!
3 还是拿DbUnifier做例子,因为没有API说明,不是很清楚你的设计。但是里面竟然有那么多close connection操作?!另外就算你关闭,
} finally {
DbUtil.closeResultSet(rs);
DbUtil.closeStatement(ps);
if (this.con == null) {
DbUtil.closeConnection(con);
}
}
closeResultSet/statement都是抛异常的,所以你的con还是可能没关闭——当然你的if,con是不可能关闭的
4 所有ColumnType相关的if, else if 链(包括判断ColumnType,还是DbUtil返回ColumnType的判断),统统改成switch,无论是效率上还是美观度上
5 小贴士。很多较新的JDBC驱动,直接ResultSet.getObject会自动根据列的类型,返回适合的Java类型。当然,我没有试过全部驱动。