每個請求或每個用戶的休眠會話數量？

Question

考慮到我們正在計劃開發一個非常大的企業應用程序。在這種情況下，應該是以下最佳方式。

a）每個請求或每個用戶的休眠會話數量？
b）申請中允許的交易數量？
c）連接池和hibernate會話之間的關係？
d）休眠會話和JTA事務之間的關係？ e）休眠會話的數量是否會降低性能？如果是的話，原因是什麼

謝謝。

Answer 1

a）每個請求。它更具可擴展性並允許物理JDBC連接池。

b）每個請求將是一個事務。此事務可能跨越不同的事務資源。在這種情況下，你主要對數據庫感興趣。對於每個數據庫，將創建一個會話（假設數據庫在特定請求中被訪問）。在請求週期結束時，所有事務資源都將被提交，或者沒有提交（兩階段提交）。在託管環境（應用程序服務器）中，事務資源隱式地加入到當前線程訪問時發生的事務中。用戶（您的應用程序）可以與此事務交互以使用JTA API設置邊界（請參閱UserTransaction）。

c）每個新創建的會話都將從連接池接收連接。

d）在每JTA事務的每個數據庫

e）是最一個Hibernate的Session。我假定每個會話實際上都用於對數據庫執行某些操作（請參閱上述要點）。首要原因是應用程序服務器和數據庫服務器資源（CPU，內存，網絡）的自然瓶頸。第二個原因是與數據庫鎖定（事務範圍）有關，並且間接地使用了版本鎖定方案（對話範圍）

當在容器外部時，您必須使用獨立連接池/ JTA實現。一個例子是使用XaPool的JOTM。但是，Hibernate擁有API，可以與我所見過的JOTM和C3P0等東西進行交互。

Answer 2

a）對於單個數據庫，您只能創建一個會話工廠，並且可以創建任意數量的會話。

b）數據庫（或系統）事務邊界總是必需的。在數據庫事務之外不可能發生與數據庫的通信（這似乎混淆了許多習慣於自動提交模式的開發人員）。始終使用明確的事務邊界，即使對於只讀操作。根據您的隔離級別和數據庫功能，這可能不是必需的，但如果您始終明確劃分事務，則不存在缺點。但是，當您需要在EXTENDED持久性上下文中保留修改時，您必須在事務外執行操作。

C）hibernate Session是一個包裝連接的包裝，它允許你在不直接寫SQL的情況下保存你的POJO。

所以一個hibernate Session是一個圍繞Connection的包裝。連接保存在連接池中。

當您調用SessionFactory.openSession時，hibernate會首先從提供的連接池中獲取一個Connection。然後它圍繞該Connection創建一個會話並返回它。