我目前正在部署到GlassFish的企業應用程序。我試圖找出從已部署到GlassFish 3.1的EJB中與cassandra後端進行通信的正確方式。我會優先使用Pelops與Cassandra交談。在Java EE中使用Cassandra（GlassFish）
聲明：我不熟悉Java EE和企業應用程序服務器和EJB背後的概念;這個項目的目的之一就是學習這些主題。這不在這個問題的範圍之內，因爲我真的只是希望指出最佳實踐的正確方向，或者我應該去尋找最佳實踐;到目前爲止谷歌並沒有非常有幫助/一致的這個話題。
更具體地說，我應該考慮爲cassandra寫一個JCA連接器嗎？使用通過Pelops與cassandra對話的單例EJB？只需在我的EJB中直接使用pelops？ （儘管我認爲你不應該在ejbs中創建套接字連接）完全是其他的東西？
我們現在正在開發一個類似的應用程序，即使我們沒有實現EJB，我們也會在Glassfish 3.1上部署一個後端，並在內部創建一個與Cassandra進行對話的小型庫。
眼下用於連接和與卡桑德拉工作最常用的庫赫：
https://github.com/rantav/hector
這是非常積極的發展。我從來沒有在EJB中看到它的使用，但我使用它，它非常可靠。不要如何開發Pelops。
我們在這裏開發的是一個非常適合我們需求的定製應用程序，這就是爲什麼我們首先不使用Hector。
只要你在EJB中使用客戶端套接字，你應該是安全的，對EJB的限制是服務器套接字，應該由應用服務器來處理。但是如果你有其他需求，你應該寫你的JCA。
EJB規範禁止EJB打開服務器套接字，但不打開套接字。但是，它也禁止EJB創建線程。 Pelops（或Hector）是否創建線程來處理其池？
拋開法律的書信，因爲這兩個圖書館都在進行合併，他們肯定覺得屬於我的資源適配器層。我會對EJB的緊張感到擔憂，EJB的生命週期是由容器控制的，並且可能很短，掛在資源上，比如連接池的生命週期有些獨立，應該更長一些。也就是說，EJB的大部分實現都是相當寬容的，所以直接從EJB中使用Pelops/Hector在架構上是否正確，它很可能會工作。
如果我在世界上的所有時間，我會寫一個資源適配器包裝這些庫中的一個或另一個。然而，這將是相當可觀的資源投入，以追求微不足道的實際回報。