我在Webpshere Application Server 6.1内运行一个web应用程序。这个web应用程序有一种规则类型的引擎，每个规则都从websphere数据源池获取它自己的连接。因此，我看到在运行用例时，对于100条输入记录，从池中获得约400-800个连接并将其释放回池中。我有一种感觉，如果这台发动机投入生产，完成加工可能需要很长时间。连接池 - 它有多少开销？
经常从池中获取连接是否是不好的做法？从池中获取连接所涉及的开销成本是多少？我的猜测是所涉及的成本应该是最小的，因为池不过是资源缓存。如果我错了，请纠正我。
如果另一个用户连接到数据库的就绪连接被移交了，并且数据库不必重新打开一个连接，连接池可以让您的连接保持预期状态。
这实际上是一个好主意，因为打开连接不仅仅是一次性的事情。有很多旅行到服务器（身份验证，检索，状态等）因此，如果您的网站上有连接池，则可以更快地为您的客户提供服务。
除非您的网站没有被人访问，否则您无法承担无法为您的连接池工作的情况。
泳池似乎不是你的问题。真正的问题在于，在完成整个计算之前，您的“规则引擎”不会将连接释放回池中。看起来，引擎不能很好地扩展。如果数据库连接的数量在某种程度上取决于正在处理的记录数量，那么事情总是非常错误！
如果您设法让您的引擎尽快释放连接，那可能只需要几个连接而不是几百个连接。如果不这样做，你可以使用连接包装，每次规则引擎要求一个连接包时都会重新使用相同的连接，这有点否定了拥有连接池的好处......
更不用说它引入了很多多线程和事务隔离问题，如果连接是只读的，它可能是一个选项。
我曾创建一个web应用程序，通过计算（通过函数将函数传递给函数）保持连接的活动状态，以便每个函数都不必从池中获得它自己的连接。但是这是一个糟糕的主意（正如你指出的那样），因为这些功能比数据检索要多得多。所以是的，尽快释放你的连接。 – 2009-07-19 12:08:32
连接池都是关于连接重用的。
如果您在不需要连接的时候坚持连接，那么您将阻止该连接在其他地方重新使用。如果你有很多线程这样做，那么你还必须运行一个更大的连接池来防止池耗尽。更多的连接需要更长的时间来创建和建立，并且需要更多的资源来维护;随着连接数量的增加，将会有更多的重新连接，并且数据库服务器也将受到更多连接数量的影响。
换句话说：你想用尽可能小的池来运行而不用耗尽它。而做到这一点的方法是尽可能少地保持联系。
我自己实现了一个JDBC连接池，虽然很多池实现可能会更快，但您可能不会注意到，因为在池中发生的任何松弛很可能会比它的时间更加矮化需要在您的数据库上执行查询。
总之：连接池只是爱它当你返回他们的连接。或者他们应该无论如何。
不要重新发明轮子。改为使用一个好的游泳池实施 - 你将需要一些时间（哦，陈旧的连接挂？等） – 2009-11-27 20:43:23
要真正检查您的游泳池是否是瓶颈，您应该介绍您的程序。如果您发现游泳池存在问题，那么您有调整问题。一个简单的池应该能够处理每秒或更多或大约10微秒的100K分配。但是，只要您使用连接，就需要200至2,000微秒才能完成一些有用的操作。
我认为这是一个糟糕的设计。听起来像一个Rete规则引擎横行。
如果您假设每个线程最少0.5-1.0 MB（例如堆栈等），则会导致大量内存崩溃。检查连接池中的连接将是你的问题中最少的。
知道最好的方法是做一个性能测试，测量内存，每个操作的挂钟时间等等。但是这听起来不会很好。
有时候我会看到人们认为只是因为它是“标准”和高科技，所以他们把所有的规则都扔进了Blaze或ILOG或JRules或Drools。这是一个了不起的简历项目，但有多少这些解决方案可以通过更简单的表格驱动决策树更好地服务？也许你的问题就是其中之一。
我建议你得到一些数据，看看是否有问题，并准备重新设计，如果数据告诉你它是必要的。
你能否提供更多关于你的规则引擎的确切功能的细节？如果每个规则“开火”正在执行数据更新，则可能需要验证连接是否正确释放（将其放在代码的finally块中以确保连接真正释放）。
如果可能，您可能需要考虑将数据更新捕获到内存缓冲区，并仅在规则会话/调用结束时写入数据库。
如果数据库操作是只读的，请考虑缓存信息。
尽管您认为400-800个连接正在创建并发布到池中，但我认为如果您必须创建并关闭400-800个unpooled连接，情况会更糟糕。
通常，默认连接池和数据源属性并不总是适合您的生产环境。您可能需要将诸如“最大连接数”和“语句缓存大小”等属性调整为高于10的值。 – svachon 2009-07-23 21:51:10