有狀態的EJB與擴展的持久化上下文來處理用戶會話

我使用CDI會話作用域bean來保存用戶相關信息（他的用戶實體bean，證書等）。每次用戶更改其信息（如電子郵件，密碼等）時，我都有一個保存方法。但是，我可以使用具有擴展持久性上下文的有狀態會話Bean來執行此操作。如果我這樣做了，他的用戶實體將在他的會話期間得到管理，並且對他的電子郵件等的更改將被同步，而不會重新創建持久化上下文等。這是個好主意嗎？我應該有一個擴展的持久性上下文打開這麼久嗎？這也鎖定用戶對外部bean的更改是否正確？如果我有一位管理員試圖對該用戶進行更改（可能會發生），該怎麼辦？有狀態的EJB與擴展的持久化上下文來處理用戶會話

來源

2011-06-14 arg20

有幾個副作用需要注意。

首先，用於保存此用戶實體的擴展持久性上下文不應該用於其他任何事情，因爲它會自動緩存正在觸及的所有內容（L1緩存）。

如果您需要在處理某些其他持久性上下文的其他操作中使用此連續附加的用戶實體，則需要獲取新實例而不是在會話範圍中使用該實例。

鎖定的事情不會自動發生。通常，不同的持久化上下文也可以修改同一個實體。通常最後一個做任何寫操作都會「贏」。如果您想防止這種情況發生，您可以利用JPA中的正常鎖定操作。對於這種情況，樂觀鎖可能是最適合的。

我很好奇，雖然這將在實踐中有多好。這當然是一個新奇的想法。通過閱讀許多博客文章，文章，書籍和與許多開發人員的討論，我感覺到擴展的持久化上下文並不是什麼已知的東西，也沒有爲它創建多少最佳實踐。

有狀態會話bean現在可以通過CDI作用域（並因此在例如HTTP會話被銷燬時自動銷燬）的事實使得整個概念更加可行。但是，CDI也是相對較新的，許多人仍然需要發現如何最好地使用它。

來源

2011-06-14 19:24:08

+1 - 對於你對CDI概念的新穎性所說的話，無法達成一致，因爲有些人仍然對所有這些「有狀態的東西」持懷疑態度:-)希望像這樣的問題/討論有助於降低簡單地試用它的障礙... – 2011-06-15 10:06:23

hi Arjan，你如何將SFSB綁定到HttpSession？這是否默認完成？在httpsession超時後它會被銷燬嗎？ – arg20 2011-06-17 10:44:05

默認情況下，它絕對不會綁定到HttpSession。爲此，您需要將bean與CDI結合使用並使用@ javax.enterprise.context.SessionScoped註釋。 – 2011-06-17 18:43:31

我使用各種Java EE 6個的項目的擴展持久化上下文，這是該方案：

一個「門面」（SFSB），注射服務（S）
一個「服務「噴射EM
一個」 dbproducer「產生EM到立面的對話範圍
門面具有所有交易被禁用默認（例如loadEntity()沒有交易）
某些立面方法明確使交易（如。 saveEntity()有TRANSATION）

發生什麼事是：

一個實體加載和對話（由持久化上下文，完美緩存的整個持續時間撐管理它 - 在沒有一筆交易 - 不會刷新）。
如果（並且僅當爲了示例的緣故）保存實體，則事務將被明確地打開，並且如果事務成功，則將持久化上下文刷新到數據庫中。
如果任何其他編輯也發生（例如，由管理員），一個OptimisticLockingException會被拋出，並且應用程序

這就像一個風情萬種，太感覺很優雅的處理： - ）

一個字的警告 - 因爲EM不可序列化 - * 如果*您正在集羣中工作，您將被迫使用粘滯會話策略，因爲這些EJB無法從一臺服務器到另一臺。

您可能還想考慮一些讓EM加入現有事務的方法（如果每個請求有多個服務調用，這很容易發生）。如果您使用非Seam 3堆棧，則代理EM是一個選項，如果您使用Seam 3，請使用@Unwraps（焊接）而不是@Produces並檢查是否有要加入的事務。

來源

2011-06-15 08:26:15

有狀態的EJB與擴展的持久化上下文來處理用戶會話

回答

相關問題