JavaWeb应用开发案例教程第七章 JDBC高级技术.ppt

7.4 Connection Pooling（连接池） 7.4 Connection Pooling（连接池） 通过实现JDBC的部分资源对象接口(?Connection,?Statement,?ResultSet?)，在?Snap-ConnectionPool内部分别产生三种逻辑资源对象 :? PooledConnection,?PooledStatement和?PooledResultSet。它们也是连接池主要的管理操作对象，并且继承了JDBC中相应的从属关系。这样的体系有以下几个特点：? 透明性。在不改变应用原有的使用JDBC驱动接口的前提下，提供资源管理的服务。应用系统，如同原有的?JDBC，使用连接池提供的逻辑对象资源。简化了应用程序的连接池改造。 资源封装。复杂的资源管理被封装在?Snap-ConnectionPool内部，不需要应用系统过多的干涉。管理操作的可靠性、安全性由连接池保证。应用的干涉（如：主动关闭资源），只起到优化系统性能的作用，遗漏操作不会带来负面影响。 7.4 Connection Pooling（连接池） 资源合理应用。按照JDBC中资源的从属关系，Snap-ConnectionPool不仅对Connection进行缓冲处理，对Statement也有相应的机制处理。合理运用Connection和Statement之间的关系，可以更大限度地使用资源。所以，Snap-ConnectionPool封装了Connection资源，通过内部管理PooledConnection，为应用系统提供更多的Statement资源。 资源连锁管理。Snap-ConnectionPool包含的三种逻辑对象，继承了JDBC中相应对象之间的从属关系。在内部管理中，也依照从属关系进行连锁管理。例如：判断一个Connection是否超时，需要根据所包含的Statement是否活跃；判断Statement也要根据ResultSet的活跃程度。 7.4 Connection Pooling（连接池） ConnectionPool是Snap-ConnectionPool的连接池对象。在Snap-ConnectionPool内部，可以指定多个不同的连接池(ConnectionPool)为应用服务。ConnectionManager管理所有的连接池，每个连接池以不同的名称区别。 通过ConnectionManager，可以同时管理多个不同的连接池，提供统一的管理界面。在应用系统中通过ConnectionManager和相关的配置文件，可以将凌乱散落在各自应用程序中的数据库配置信息（包括：数据库名、用户、密码等信息），集中在一个文件中。便于系统的维护工作。 7.4 Connection Pooling（连接池） 7.5 分布式事务 获得一个用来支持分布式事务的连接与获得连接池中的连接是很相似的。不同之处在于DataSource实现上的不同，而不是在应用程序中获得连接的方式上有什么不同。假设DataSource的实现可以与支持分布式事务中间层服务器一起工作，得到连接的代码还是如下所示： Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup(jdbc/EmployeeDB); Connection con = ds.getConnection(myPassword, myUserName); 从应用程序设计者的观点来看。是否支持分布式的事务的连接对它来说没什么不同，唯一的不同是在事务的边界上（开始一个事务的地方和结束一个事务的地方），开始一个事务或者结束一个事务都是由事务服务器来控制的。应用程序不应该做任何可能妨碍服务的事情。应用程序不能够直接调用事务提交commit或者回滚rollback操作，也不能够使用事务的自动提交模式auto-commit mode（在数据库操作完成的时候自动的调用commit或者rollback）。 7.5 分布式事务 7.5 分布式事务 在一个连接参与了分布式事务的时候，下面的代码是不能做的（con表示支持分布式事务的连接Connection）。 mit(); 或者 con.rollback(); 或者 con.setAutoCommit(true); 对于通常的Connection来说，缺省的是auto-commit模式。而对于支持分布式事务的Connection来说，缺省不是auto-commit模式。注意，即使Connection是支持事务的，它也可以用于没有事务的情况。关于事务边界的限制只是对分布式事务的情况下才成立的。 7.5