哪个网站可以做奖状,二维码怎么在网站上做推广,重庆住建网站,西安刚刚宣布1. 前言 在基于 J2EE 平台的应用开发中#xff0c;大多数的应用都需要跟数据库打交道#xff1b;而自从接触 JDBC 起#xff0c;我们便不止一次的被告之#xff1a;数据库资源是十分宝贵的系统资源#xff0c;一定要谨慎使用。但令人遗憾的是#xff0c;在笔者… 1. 前言 在基于 J2EE 平台的应用开发中大多数的应用都需要跟数据库打交道而自从接触 JDBC 起我们便不止一次的被告之数据库资源是十分宝贵的系统资源一定要谨慎使用。但令人遗憾的是在笔者见过的大部分跟数据库相关的应用开发中针对数据库资源的使用总是充斥着这样或者那样的问题。在本文中笔者针对常见的一些错误或者不当的使用数据库资源的案例进行介绍与分析并阐述金蝶 Apusic 应用服务器提供的一些增值特性通过这些特性能够有效的避免某些错误的发生。 2. 常见数据库资源错误/不当用法的案例分析 2.1. 未正确的关闭数据库连接 申请了数据库连接却没有及时的关闭它这几乎是最常见的数据库连接使用错误。犯这种错误的原因有很多以下是常见的一种低级错误 publicvoidfoo(){ ConnectionconngetConnection(); Statementstmtnull; try{ conngetConnection(); stmtconn.createStatement(); }catch(Exceptione){ }finally{ close(stmt,conn); } } 示例代码一 在上述案例中的第 2 行代码中作者已经申请了一个 Connection 但在第 5 行代码中又申请了一个新的 Connection 并且丢失了第一次申请的 connection 的引用至此当程序每调一次 foo 方法将导致申请一个新的 Connection 而没有释放它如此一来当数据库达到能够承受的最大连接数时将导致整个应用的运行失败。 避免这种错误的方法有很多譬如可采用类似于 FindBugs( 注 1) 的代码分析工具对应用的源码进行分析找出可能产生错误的代码。 此外在应用中我们需要非常频繁的对申请的数据库连接进行关闭与释放此时建议封装成某些工具类使用并且要尽可能安全的关闭数据库连接。下面我们以关闭 Statement 及 Connection 的通用 close 方法的不同实现方案来比较 不安全的关闭方法 privatevoidclose(Statementstmt,Connectionconn){ try{ stmt.close(); conn.close(); }catch(Exceptione){} } 示例代码二 在上述代码中倘若第 3 行代码中的 stmt 为空或者 stmt.close() 方法出错并抛出异常都将使第 4 行代码不能够正常调用从而导致数据库连接无法释放那么更安全的写法应该是 安全的关闭数据库资源方法 privatevoidclose(Statementstmt,Connectionconn){ try{ if(stmt!null)stmt.close(); }catch(Exceptione){} try{ if(conn!null)conn.close(); }catch(Exceptione){} } 示例代码三 在修订后的代码中我们可以看到无论第 3 行代码中关闭 stmt 是否成功程序都能够保证向下执行从而正确的关闭 conn 。 这些常用的数据库资源操作公用类可以使用 Apache 的 CommonsDbUtils( 注 2) 组件。 2.2. 任意的申请数据库连接 不考虑事务上下文任意的申请数据库连接资源也是常见的一种不当用法。但这种问题往往是难以克服的根源在于 Java 是一种面向对象的语言而数据库的事务却是一种批量化的操作过程。我们以常见的“序列号”的实现方案为例在某些应用场景中我们需要一种自增长的整数型字段但由于不同的数据库有不同的实现所以为达到各个数据库兼容的目的我们常用的解决方案是新建一张 T_SEQUENCE 表它可能包含的字段有 NAMEvarchar(100),CURRENT_VALnumber(10) 其中 NAME 存放序列的名称而 CURRENT_VAL 存放序列的当前值。假设某一业务对象 Customer 需要新增一笔记录时为获得不重复且自增长的 CustomerID 需要将 T_SEQUENCE 表中的与该业务表对应的序列号加 1 并更新然后将更新后的值作为 Customer 的 ID 如下述表格所示 T_SEQUENCE NAME CURRENT_VAL CUSTOMER 10 T_CUSTOMER ID CUSTOMER_NAME 9 Kevin 10 Mary 于是在 Java 语言中我们以面向对象的方法来实现可能会是这样常见写法未必是最优实现 publicclassCustomer{publicvoidsequencePlus(){Connectionconnnull;Statementstmtnull;try{conngetConnection();stmtconn.createStatement();StringsqlupdateT_SEQUENCEsetCURRENT_VAL CURRENT_VAL1whereNAMECUSTOMER;stmt.execute(sql);}catch(Exceptione){e.printStackTrace();}finally{DbUtils.closeQuietly(stmt);DbUtils.closeQuietly(conn);}}publicintgetSequenceCurrentVal(){Connectionconnnull;Statementstmtnull;ResultSetrsetnull;intid0;try{conngetConnection();stmtconn.createStatement();StringsqlselectCURRENT_VALfromT_SEQUENCE whereNAMECUSTOMER;rsetstmt.executeQuery(sql);if(rset.next()){idrset.getInt(1);}}catch(Exceptione){e.printStackTrace();}finally{DbUtils.closeQuietly(conn,stmt,rset);}returnid;}publicvoidaddCustomer(Stringname){Connectionconnnull;PreparedStatementstmtnull;ResultSetrsetnull;try{sequencePlus();intidgetSequenceCurrentVal();conngetConnection();stmtconn.prepareStatement(insertintoT_CUSTOMER(ID,CUSTOMER_NAME)values(?,?));stmt.setInt(1,id);stmt.setString(2,namenull?:name);stmt.execute();}catch(Exceptione){e.printStackTrace();}finally{DbUtils.closeQuietly(stmt);DbUtils.closeQuietly(conn);}}} 示例代码四 针对这种应用场景我们首先需要认识到上述的三个方法应该属于同一个数据库事务否则在并发情况下将出现由于主键重复而导致数据插入失败的情况。但同时我们也需要看到即便上述三个方法的执行位于同一个事务中但三个方法使用的是不同的数据库连接虽然在 sequencePlus 方法中将 T_SEQUENCE 表中的数据加 1 但在事务并未提交的情况下由于 Connection 隔离级别的原因在 getSequenceCurrentVal 方法中是看不到 sequencePlus 方法中更新以后的数据的这样也将导致数据插入失败因为主键势必跟旧有 ID 值重复。 因此传统的编程方法中为克服上述问题只有在上述的方法中使用同一个 Connection 才能够保证业务数据的正确。但这样一来将影响我们以 OO 方法分析问题时的“纯洁”性很容易让人厌倦。 2.3. 将Connection作为成员变量 另外一种常见的不当编程模式是将 Connection 作为类的成员变量。一般来说针对 Connection 我们采取的策略是用时再申请用完立即释放。而将 Connection 作为成员变量将是对该规则的严重挑战容易引起若干编程错误。举例而言成员变量级的 Connection 何时创建何时释放倘若在每一个方法体内进行 Connection 的创建与释放那么将 Connection 作为成员变量又失去了意义倘若在类的构造期内进行 Connection 的创建那么又在何时释放它呢因为在 Java 语言内你是无法控制对象的生命周期的。 将 Connection 作为成员变量还会产生另外一个问题资源的闲置浪费。因为在申请连接以后该资源将在这个对象的生命之期之内一直有效即使该对象处于非使用状况这无疑是一种资源的浪费。更有甚者倘若这种对象过多将造成数据库达到最大连接数造成应用运行失败。 3. 金蝶Apusic应用服务器的数据源管理 金蝶 Apusic 应用服务器支持业界主流的各种数据库在 Apusic 应用服务器之内进行数据源的配置与使用都非常简单同时它提供了许多增值特性能够为应用的正常运行提供额外的保障。 3.1. 数据库连接池的逻辑连接与物理连接 我们注意到 java.sql.Connection 是一个 Interface 那么真正实现这个接口的类是什么呢 我们可以做一个简单的测试案例在普通的 JavaApplication 中调用如下方法 publicvoidshowConnection(){Connectionconnnull;try{Class.forName(oracle.jdbc.driver.OracleDriver);connDriverManager.getConnection( jdbc:oracle:thin:localhost:1521:KEVINORA, system,manager);System.out.println(ConnectionClassis:conn.getClass().getName());}catch(Exceptione){e.printStackTrace();}finally{DbUtils.closeQuietly(conn);}} 示例代码五 得到的输出结果是 ConnectionClassis: oracle.jdbc.driver.T4CConnection 而在 Apusic 应用服务器中运行如下方法 publicvoidshowConnection(){Connectionconnnull;try{ContextctxnewInitialContext();ds(DataSource)ctx.lookup(jdbc/oracle);connds.getConnection();System.out.println(ConnectionClassis: conn.getClass().getName());}catch(Exceptione){e.printStackTrace();}finally{DbUtils.closeQuietly(conn);}} 示例代码六 得到的输出结果是 ConnectionClassis:com.apusic.jdbc.adapter.ConnectionHandle 明明用相同的 JDBCDriver 连接同一个数据库为什么取得的 Connection 却是不同的类呢事实上通过 Apusic 应用服务器获得的数据库连接其实只是一个逻辑连接真正的物理连接隐藏在该逻辑连接之内这是一个典型的 Delegate 模式而恰恰是这个模式通过 Apusic 应用服务器对数据源进行管理将给我们的应用开发带来很多好处 3.2. 当事务结束以后在该事务上下文中申请的物理连接都将主动释放 我们以一个最简单的 StatelessSessionBean 为例 publicclassSimpleBeanimplementsSessionBean{publicvoidfoo(){Connectionconnnull;try{ContextctxnewInitialContext();DataSourceds(DataSource)ctx.lookup(jdbc/oracle);connds.getConnection();System.out.println(notreleaseconnection);}catch(Exceptione){e.printStackTrace();}finally{//Notclosetheconnection//DbUtils.closeQuietly(conn);}}} 示例代码七 SimpleBean 中的 foo 方法的事务属性设置为 Required 在该方法中我们申请了一个数据库连接但并没有释放它在运行之前我们通过 SQLPlus 观察 Oracle 数据库的 Session 得到的结果是 SQL select count(*) from v$session; COUNT(*) ---------- 18 图一执行方法之前的 OracleSession 而在执行完 SimpleBean 的 foo 方法之后我们再次观察 Oracle 数据库的 Session 得到的结果是 SQL select count(*) from v$session; COUNT(*) ---------- 18 图二执行方法之后的 OracleSession 由此我们可以得知即便由于程序的书写错误没能够释放申请的数据库连接但 Apusic 应用服务器在事务完成之后能够把该事务上下文中申请的物理连接主动释放这对提升应用的容错性带来一定的好处。 3.3. 当jsp/servlet运行结束以后在jsp/servlet中申请的物理连接都将主动释放 同事务中申请的数据库连接会主动释放一样在 jsp/servlet 中申请的数据库物理连接当 jsp/servlet 运行完毕以后如果用户没有释放这些连接 Apusic 应用服务器也将予以主动释放。读者可以尝试自己做一个案例在 jsp 中申请一个连接故意不释放在 jsp 执行完毕以后可以通过 SQLPlus 或者 Apusic 性能监控工具查看连接是否已经被应用服务器主动释放。 由上述两节内容我们可以看到 Apusic 应用服务器能够有效避免 2.1 节中所描述的问题。 3.4. ConnectionSharing同一个事务上下文中申请的物理连接可以共享 通过共享连接可以更有效地使用资源及提高性能并且可以防止连接之间的资源锁定问题。 例如两个 EJB 组件 A 和 B 它们的事务属性都设置为 Required 。在调用 EJBA 的方法时打开了一个数据库连接并对数据库中的某个表进行了更新操作而在关闭连接之前 EJBA 调用了 EJBB 的某个方法同样 EJBB 打开同一个数据库的连接也对数据库中同一个表进行了更新操作。倘若没有连接共享机制这两个连接指向的是两个不同的物理连接在其上执行的数据库操作将会互相锁定而这种死锁状态是无法恢复的。现在有了连接共享机制可以有效地解决这个问题。在 EJBA 和 B 中所获得的连接对象实际上都指向同一个物理连接。这一个过程可以简单描述如下 con1getConnection();Transaction.beginperformdatabaseoperationoncon1con2getConnection();performdatabaseoperationoncon2con2.close();Transaction.commit();con1.close(); 示例代码八 无论两个连接是在事务边界之内或之外打开和关闭都没有问题。只有在一个事务边界之内连接才会被共享如果一个连接是在事务边界之外打开的那么在事务开始时会将此连接参与到事务中并找到一个具有正确事务场景的物理连接和连接对象相关联。在离开事务场景之后如果连接对象仍未关闭则将其关联到一个不具有事务场景的物理连接。 可以在部署描述中指定一个资源引用的 res-sharing-scope 属性来允许或禁止连接共享属性值 shareable 为允许共享 unshareable 为禁止共享缺省情况下为允许共享。 回到 2.2 节中 Customer 那个测试案例我们已经说过 Customer 的 sequencePlus 方法、 getSequenceCurrentVal 方法、以及 addCustomer 方法需要放在一个事务中处理。但在这三个方法中使用的是不同的 Connection 而由于 Connection 的隔离级别将导致插入 T_CUSTOMER 表中的 ID 主键将重复最终导致事务回滚。利用 Apusic 应用服务器连接共享特性能够很好的解决这个问题。也就是说虽然这三个方法申请的逻辑连接是不同的但逻辑连接内部所使用的物理连接是同一个这样将保证不同方法中对数据库的操作结果相见可见从而保证事务的正常提交。 举例如下假设在一个 jsp 文件中这样调用 % InitialContext ctx new InitialContext(); String txName java:comp/UserTransaction ; UserTransaction tx (UserTransaction)ctx.lookup(txName); tx.begin(); new Customer().addCustomer( eric ); tx.commit(); % 示例代码九 在上述代码中通过 UserTransaction 启动一个事务然后在该事务上下文中增加一笔 Customer 的记录我们发觉在不需要更改 Customer 类的情况下上述方法能够正常完成。 由此可以得知在 Apusic 应用服务器中进行应用的开发我们无需因为考虑数据库 Connection 的隔离级别而影响我们对系统的面向对象的分析方法 Apusic 应用服务器将替我们保证在同一事务上下文中使用相同的物理连接。 通过 Apusic 应用服务器的这个特性能够有效的解决 2.2 节中描述的问题。 3.5. Lazy Connection Association Optimization:数据库连接延迟关联的优化机制 在 3.1 节中我们谈到通过 Apusic 应用服务器管理的数据库连接分逻辑连接与物理连接物理连接隐藏在逻辑连接的背后。那么逻辑连接何时与一个真正的物理连接相关联的呢在关联的过程之中 Apusic 应用服务器又提供了哪些优化机制呢举例如下 J2EE 组件可能会将连接对象保存在其实例变量中从而可以在多个事务之间重复使用但是如果这个组件在使用一次之后就很少再被用到那么系统资源将会被组件白白占用而得不到释放当连接池被占满时就再也无法获得新的连接。 Lazy Connection Association Optimization 是这样一种机制当 J2EE 组件方法调用完成时释放连接对象所指向的物理连接以供其他组件使用连接对象进入一个 Inactive 状态在这个状态下它不和任何物理连接相关联。当 J2EE 组件需要使用该连接对象时容器将其激活将其和一个实际的物理连接相关联。这一过程对于应用组件来说是完全透明的。 J2EE 程序员经常犯的一个错误是忘记关闭连接特别是发生异常时没有执行正确的清理过去我们解决这一问题是在方法调用完成时强制关闭所有的连接现在有了 Lazy Connection Association Optimization 机制可以更完美地解决这一问题。 ConnectionSharing 和 Lazy Connection Association Optimization 是同时起作用的例如当一个连接被激活时它将被包含在当前事务场景中并与同一事务场景中的其他逻辑连接共享同一个物理连接。 我们在 2.3 节中强调将 Connection 作为成员变量是一种糟糕的设计模式但同时我们也看到哪怕用户旧有系统中存在这样的用法 Apusic 应用服务器也能够很好的解决由于这种糟糕的设计所带来的缺陷。 4. 总结 本文首先与读者分析了一些错误或者不当的数据库资源使用方法然后简要介绍了金蝶 Apusic 应用服务器在数据源管理上的一些特性。这些特性对应用的健壮性及容错性带来一定的好处。但需要再次提醒的是应用服务器提供的一些增值特性仅能够当作保障我们应用正常运行的最后一道屏障我们切不可依赖于这些特性而忽视程序自身的编码质量。一个 J2EE 应用能否正常的运行程序自身的设计与编码永远是主要因素。 5. 参考资料 注 1 FindBugs Sourceforge 上的一个开源工具能够对源码进行分析从而发现可能出现的编程错误 http://findbugs.sourceforge.net/ 注 2 CommonsDbUtils:ApacheJakarta 项目的 Commons 组件 http://jakarta.apache.org/commons/index.html 注 3 金蝶 Apusic 应用服务器国内首家通过 J2EE1.4 认证的应用服务器请参考 http://www.apusic.com/ 转载于:https://www.cnblogs.com/zhuyx/archive/2007/06/07/10402058.html
