爲什麼無狀態EJB被集中？

應用服務器爲什麼要共享無狀態EJB？爲什麼無狀態EJB被集中？

我可以理解，控制調用應用程序的工作負載非常有用，但這僅僅證明了使用調用者客戶端將服務器作爲FAÇADE的EJB池化。

將內部EJB（那些沒有公開並且只在內部調用來執行業務邏輯）集中起來有什麼好處嗎？而不是使用共享單個實例（就像Spring一樣）。

我至少可以考慮一個缺點：高度使用的內部EJB可能會成爲瓶頸。

來源

2012-01-16 edutesoy

無狀態會話bean EJB不一定是線程安全的。他們可以持有像JMS會話這樣的資源，這些資源一次不能與多個線程共享，因此服務器會將它們彙集到一起，以便它可以同時爲同一個bean提供多個請求（JMS資源也是共享的，但我只是使用這個例子）。

來源

2012-01-16 19:02:31 Dev

如果它是無狀態的，那麼沒有狀態被併發威脅，那麼沒有競爭條件可以出現，因此它們是線程安全的，我錯了嗎？是的，我知道他們有一些狀態，比如注入資源，但是也許他們不應該被稱爲無狀態！ :)我認爲答案是正確的。 – edutesoy 2012-01-17 09:33:28

@edutesoy我同意你的解釋。但是爲什麼國家仍然維持。 – 2014-05-14 04:53:39

我也想知道爲什麼無狀態的EJB被彙集起來。但我想知道他們爲什麼彙集而不是按需創建和銷燬。實例可以被重複用於不相關請求的事實使得無狀態bean的實現變得複雜（這意味着你必須非常小心地使用實例字段），並且我沒有看到任何顯着的好處。

具體來說，我沒有看到任何性能上的好處。我在JBoss（6，IIRC）中介紹了無狀態bean的實現，以及它的唯一bean集合實例本身;處理方法調用的管道在每次使用時都會從頭開始重新創建。這意味着唯一的性能節省是單個對象創建，這應該是一個微不足道的時間。我可以看到它是不平凡的唯一情況是，如果bean獲得重量級資源，並在調用之間持有它們。然而，在那種情況下，這個bean真的被用作一個榮耀的，管理不善的池子;正確的解決方案將是直接彙集資源！

現在，EJB已經存在很長時間了。當他們第一次出來的時候，物體的創造是昂貴的，所以將它們合併是有意義的。但那些日子早已逝去。爲什麼在EJB3中池不會丟失？

來源

2012-01-16 19:32:31

好吧，我想如果你有成千上萬的併發請求，只要你確定它們是線程安全的，而不是在內存中有成千上萬的實例，將它們集中起來，或者甚至更多，將它們創建爲@Singleton是有意義的。 – 2012-01-16 23:29:46

如果bean是線程安全的，那麼是的，單例是理想的。但是，如果不是，彙集和丟棄實例的內存負載將是相似的;混合實例實際上會讓垃圾收集器*做更多工作，因爲它們活得足夠長以逃離託兒所。 – 2012-01-16 23:42:11

這是一個很大的說法。我想這取決於每個請求處理的時間，以及這些對象在池中花費的時間。如果它們中的大多數可以在任何時間點使用，那麼您可能會比創建/銷燬獲得一些好處。這也取決於流量趨勢等。這是非常細粒度的分析IMO :) – 2012-01-17 00:01:30

爲什麼無狀態EJB被集中？

回答

相關問題