Ejb 3.0 在JavaEE中使用Cassandra（GlassFish）

我目前正在开发一个部署到GlassFish的企业应用程序。我正试图找出从部署到GlassFish 3.1的EJB中与cassandra后端通信的正确方法。我更愿意用佩洛普斯和卡桑德拉说话

免责声明：我不熟悉JavaEE以及企业应用服务器和EJB背后的概念；本项目的目的之一是学习这些主题。这超出了这个问题的范围，因为我真的只是希望被指出最佳实践的正确方向，或者我应该去哪里寻找最佳实践；到目前为止，谷歌在这个话题上并没有太大的帮助/一致性

---

更具体地说，我应该考虑为cassandra编写一个JCA连接器吗？使用通过Pelops与cassandra对话的单例EJB？直接在我的EJB中使用pelops？（虽然我认为您不应该在EJB中创建套接字连接）完全是另外一回事吗？

我们正在开发一个类似的应用程序，我现在工作的地方，即使我们没有实现EJB，我们也会在Glassfish 3.1中部署一个后端，在内部我们创建了一个与Cassandra对话的小型库

目前，连接和使用Cassandra最常用的库是Hector：

这是非常积极的发展。我从未见过它在EJB中使用，但我使用了它，它非常可靠。但不知道Pelops是如何开发的

我们在这里开发的是一个非常定制的应用程序，适合我们的需要，这就是为什么我们最初没有使用Hector

---

只要您在EJB中使用客户机套接字，就应该是安全的，EJB上的限制是针对应由应用服务器处理的服务器套接字。但是如果您有其他需要，您应该编写JCA。

EJB规范禁止EJB打开服务器套接字，但不允许打开套接字。但是，它也禁止EJB创建线程。Pelops（或Hector）是否创建线程来处理其池

撇开法律条文不谈，因为这两个库都进行了池化，所以它们肯定感觉像是属于我的资源适配器层的东西。我会对EJB感到紧张，它的生命周期由容器控制，并且可能很短，它依赖于一个资源，比如一个连接池，它的生命周期有些独立，应该更长

也就是说，EJB的大多数实现都是相当宽容的，因此无论直接从EJB使用Pelops/Hector在体系结构上是否正确，它都很可能工作

如果我有足够的时间，我会编写一个资源适配器来封装其中一个库。然而，为了追求微不足道的实际回报，这将是一项巨大的资源投资