二、Connection pooling（连接池）：
连接池是这么一种机制，当应用程序关闭一个Connection的时候，这个连接被回收，而不是被destroy，因为建立一个连接是一个很费资源的操作。假如能把回收的连接重新利用，会减少新创建连接的数目，显著的提高运行的性能。
假设应用程序需要建立到一个名字为EmpolyeeDB的DataSource的连接。使用连接池得到连接的代码如下：
Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("jdbc/EmployeeDB");Connection con = ds.getConnection("myPassWord", "myUserName");除了逻辑名字以外，我们发现其代码和上面举的例子的代码是一样的。逻辑名字不同，就可以连接到不同的数据库。DataSource对象的getConnection方法返回的Connection是否是一个连接池中的连接完全取决于DataSource对象的实现方法。假如DataSource对象实现与一个支持连接池的中间层的服务器一起工作，DataSource对象就会自动的返回连接池中的连接，这个连接也是可以重复利用的。
是否使用连接池获得一个连接，在应用程序的代码上是看不出不同的。在使用这个Connection连接上也没有什么不一样的地方，唯一的不同是在Java的finally语句块中来关闭一个连接。在finally中关闭连接是一个好的编程习惯。这样，即使方法抛出异常，Connection也会被关闭并回收到连接池中去。代码应该如下所示：
try{…
}catch（）{…
}finally{ if（con!=null）con.close();}
三、分布式事务：
获得一个用来支持分布式事务的连接与获得连接池中的连接是很相似的。同样，不同之处在于DataSource的实现上的不同，而不是在应用程序中获得连接的方式上有什么不同。假设DataSource的实现可以与支持分布式事务中间层服务器一起工作，得到连接的代码还是如下所示：
Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("jdbc/EmployeeDB"); Connection con = ds.getConnection("myPassword", "myUserName");由于性能上的原因，假如一个DataSource能够支持分布式的事务，它同样也可以支持连接池治理。
从应用程序设计者的观点来看。是否支持分布式的事务的连接对它来说没什么不同，唯一的不同是在事务的边界上（开始一个事务的地方和结束一个事务的地方），开始一个事务或者结束一个事务都是由事务服务器来控制的。应用程序不应该做任何可能妨碍服务的事情。应用程序不能够直接调用事务提交commit或者回滚rollback操作，也不能够使用事务的自动提交模式auto-commit mode（在数据库操作完成的时候自动的调用commit或者rollback）。
