对于java使用者来说，操作数据库JDBC连ODBC是十分常
用的方法。在基于JDBC的应用当中，许多工作都是围绕java。
sql。Connection接口展开的。做任何数据库操作之前，应用必
须创建一个数据库Connection，此连接则相当于应用和数据库之
间的一个信息通道，承载应用发送的SQL语句及数据库返回的结
果。Connection会与一个数据库用户账户相关联，从而使得数据
库能够对通过Conection提交的SQL语句施加一些访问控制规则。
最后，Conection还是数据库事务的边界。只有通过同一个
Connection执行的SQL语句才能组成一个事务。事务由多条SQL语
句组成，这些SQL语句要么全部成功，要么作为一个原子操作全
部失败。同过调用Connection方法，可以提交事务，也可以回滚
事务。
在一个独立的应用中，Connection通常只创建一次，而
且在应用关闭前一直保持打开。独立的应用一次仅为一个用户提
供服务，而由一个用户所启动的所有数据库操作通常会相互关联
。在一个服务器应用中，如果它要处理来自多个不同的用户的彼
此无关的请求，处理连接就没有那么显而易见了。在此需要考虑
的是：Connection的创建相当的耗费时间，一次只能用于一个用
户以避免事务崩溃，而要保持连接打开其代价也很大。
创建Connection的实际操作需要大概花费1-2秒。除了
与数据库建立一个网络连接之外，数据库引擎必须对数据库用户
进行鉴别，并创建一个包含各种数据结构的上下文来跟踪记录事
务、所缓存的语句、结果等等。若为服务器接收到的每个请求都
创建一个Connection，尽管实现简单，但是对于大流量的服务器
应用来说，却要花费太多的时间。
要使创建连接所需要的时间尽可能减少，一直方法就是
为每个需要访问数据库的Servlet或JSP页面维护一个Connection
。Connection可以在初始化web资源的时候创建，并保存在一个
实例变量中，直到应用关闭。可以发现，基于这种方法部署一个
应用的时候，将会导致大量多线程问题。每个请求都作为一个单
独的线程通过同一个Servlet或JSP页面执行。有些JDBC驱动程序
根本不支持多线程访问同一个Connection，这就带来了各种各样
的运行时错误。还有一些JDBC驱动程序通过将所有调用串行化来
支持多线程访问同一连接，这又会带来扩展性差的问题。这种方
法还存在一个严重的问题，即来自多个用户的请求都使用同样的
Connection，这样就会在同一个事务中操作。如果一个请求回滚
，那么就可能导致同一Connection的所有其他数据库操作都要回
滚。
从服务器资源（内参）的角度看，保持连接打开代价也
很高。许多 商业数据库产品使用的许可证都是基于同时打开的
连接数来定价，因此即便是从实际的花销上来看，连接也是很昂
贵的。由此看来，尽量减少应用所需的连接数的确是一个明智之
举。相应于“每一个资源一个Connection”的做法，还有一种方
法是在接收第一个请求的时候为每一个用户创建一个Connection
，并将其作为一个会话作用域对象。不过，这种方法有一个缺点
，即Connection可能在大多数时间内处于未激活状态，因为用户
在做下一个请求之前需要一定的时间来查看前一个请求的结果。
最好的做法是使用一个连接池。连接池包含一些
Connection对象，这些对象由所有Servlet和JSP页面所共享。对
于每个请求，会从池中选出一个Connection，使用后再将其放回
池中。使用连接池即可解决其他做法所存在的问题：
如，创建连接相当耗费时间
置于池中的Connection仅创建一次，然后会得到重用。
大多数池实现都允许指定开始时Connection对象的起始数，还可
以指定最大连接对象数。可以根据需要创建新的Connection对象
，直到达到最大数为止。一旦达到了最大连接数，池的客户等待
一个现有的Connection对象重新可用，而不会创建一个新的连接
对象。
对于共享连接存在多线程问题
利用池，每个请求都会得到其自己的Connection，因此
一次仅由一个线程使用，从而消除了所有潜在的多线程问题。
连接是有限资源
利用池，每个Connection都将得到高效使用。只要有未
处理的请求，Connection就不会空闲。连接池允许指定
Connection对象的最大数，还可以将同时连接数的许可证限制与
可接受的响应时间加以权衡。
不过，连接池并不是万能的。因为所有用户都使用同样
的Connection，因此不能依赖于数据库引擎逐个的限制用户对受
保护资源的访问。相反，必须按脚色来定义数据访问规则，所谓
角色就是有相同访问权限的用户组。然后可以对不同角色使用不
同的池，每个池利用数据库帐户（对应角色）来创建Connection
对象。
