给你一点解释的文字：
连接池是这么一种机制，当应用程序关闭一个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）。
连接池是这么一种机制，当应用程序关闭一个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）。
解决方案 »
- 求助--关于业务逻辑的实现层的困惑
- 合并 2张 execl 表
- 用update触发器修改自身表会不会造成循环触发？
- 求SQL语句
- 能否查看store procedure是否有被執行過???
- 请教一个问题:如果数据量上百万,但是我每次读取的就10条,会不会影响速度?
- bcp 的用法，有关数据库 SQL server 2000
- sqlserver2000数据库，如何在存储过程中将int类型id字段设置为自增？
- 请问使用select后未找到数据, 这时在SQL中是什么装态?
- 关于分级游标和数据构形的优势讨论
- 谁有oracle 8i for solaris x86版本的数据库,价格可以商量,并送20分
- 关于增加表的字段问题的提问,请帮忙，谢谢！
麻烦了；）
1 如果使用连接池的话，并设置SQL Server使用池连接，然后设置60秒.这里的60秒是什么意思呢？ 如果是60秒后无用的连接会自动断开并导致句柄无效，可是实际没有哇。2 上次你帮我回答过问题的。像我这样用长连接，需要如何设置（如连接池）呢？
2.与一些复杂的连接池相比,ODBC的此项功能基本上被弃之不用了,功能太简单.
感觉只需要将其打开,程序在连接时就不需要做其它工作,该打开时打开,该关闭时关闭,知道系统给你的只是一个连接不是不同的多个连接就行了.
至于那个60秒,我也感觉十分费解.
因为有可能会出现异常导致链接断掉，我在类成员函数ExectueSQL中执行SQL语句前加入判断，如断开则重新Init... Connect...， 是吧。再问一下guo,用ODBC API如何检测当前连接状态？
ODBC接口函数... 记不得了
我很土,菠萝蜜是菠萝还是榴莲?