以下是我們可以用於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爲您提供了大多數選項。這通常不是一個管理頭疼的問題，但如果你在一臺機器上運行它，好處是有限的。如果您至少有兩臺機器（應用程序服務器和數據庫服務器），那麼這是一個簡單的解決方案，通常可以防止很多系統過載。