以下是我们可以用于Web应用程序环境中的数据库连接的不同技术。Web应用程序中的数据库连接
Application Context Database Connection:只有一个数据库连接在所有请求之间共享。Database Pooling:打开固定数量的数据库连接并共享所有请求之间的连接。New Database Connection per request:为每个请求打开一个连接。这些技术的优点和缺点是什么？开发人员应该使用哪一个？
选项1.在所有Web用户之间共享单个数据库连接肯定会因为某种原因失败。一个长时间运行的查询和您的整个服务器将停止运行。对于99.9％的所有现代应用程序，即使是基于非网络的应用程序，这是一个难以实现的“否定”。
选项2.连接池。可能是Web应用程序连接到数据库的第二种最常用的技术。首先，如果数据库和Pool/web应用程序位于同一台机器上，则其优势非常有限。然而，游泳池和网络应用程序可以很容易地存在于相同的硬件上。这样做的好处是数据库连接的开放成本很高，并且开放程度较低，开销较高。打开连接需要CPU使用和内存分配。连接池可以让几十个连接几乎立即“连接到”。内存将被分配，大部分设置工作已经完成，因此连接和断开池的操作相对来说比较che。。池通常保持一定数量的连接开放，并随着流量的增加而增长。在流量过大时，池通常会将连接请求排队，以便数据库不会过载。队列后端的用户会遇到延迟，但系统会搅动，并且由于缺少内存而一般不太可能停下来和磁盘交换。
选项3.每个请求的新数据库连接。在轻度到中等利用率的系统上，这不是一个可怕的选择，通常很容易在以后升级到池塘。但请记住，每个数据库连接（每次页面加载）都需要打开和关闭数据库连接，这涉及CPU和内存分配。在实践中，如果你的页面加载速度很快，你的用户基数很小且一致，并且你的流量相当一致，它可以正常工作。许多DEV，CAT和QA环境直接连接，无需打印机。缺点是＃1，绝对没有办法控制到数据库的连接。如果查询挂起，您可能会有数百个连接突然中断您的数据库，并且有时需要重新启动或重新启动数据库才能纠正这种情况。
例如：您在网站的首页上写了1个错误的查询，导致它运行3秒而不是0.3秒。最终，您的网站在任何时刻都有1-2个页面，现在可能会达到10-20。现在这10-20页= 10-20个DB连接不断打开和关闭，平均打开10-20个连接。这个问题会越来越多，使用越来越多的内存，直到达到连接限制（或者更糟的是，用尽所有内存和所有东西，现在交换）。此时，一切都停止了。
请记住，连接占用数据库和应用程序服务器/池中的资源。当你的数据库被分页到磁盘时，大多数时候，所有的希望都会在没有重新设置的情况下失去一个正常的恢复 - 显然它可能会发生，但是如果没有代码修复，你通常会重新启动，给自己更多的时间，直到问题不可避免地再次发生，并希望到那个时候，你已经找到了错误的查询，或错误的配置并修复它。
选项2为您提供了大多数选项。这通常不是一个管理头疼的问题，但如果你在一台机器上运行它，好处是有限的。如果您至少有两台机器（应用程序服务器和数据库服务器），那么这是一个简单的解决方案，通常可以防止很多系统过载。