在 Java EE 中使用 Cassandra (GlassFish)
我目前正在开发一个部署到 GlassFish 的企业应用程序。我试图找出从已部署到 GlassFish 3.1 的 EJB 内与 cassandra 后端通信的正确方法。我更喜欢使用 Pelops 与 Cassandra 交谈。
免责声明：我对 Java EE 以及企业应用程序服务器和 EJB 背后的概念不熟悉；该项目的目的之一是学习这些主题。这超出了这个问题的范围，因为我实际上只是希望指出最佳实践的正确方向，或者我应该去哪里寻找最佳实践；到目前为止，谷歌在这个主题上还没有非常有帮助/一致。
更具体地说，我应该考虑为 cassandra 编写 JCA 连接器吗？使用通过 Pelops 与 cassandra 对话的单例 EJB？直接在我的 EJB 中使用 pelops 吗？ （虽然我认为你不应该在 ejbs 中创建套接字连接）完全是别的东西吗？
I am currently working on an enterprise application that is deployed to GlassFish. I am attempting to figure out the right way to communicate to a cassandra backend from within an EJB that has been deployed to GlassFish 3.1. I would prefere to use Pelops to talk to Cassandra.
Disclaimer: I am new to Java EE and the concepts behind enterprise app servers and EJBs; one of the purposes of this project is to learn these topics. This is out of scope of this question as I am really just looking to be pointed in the right direction for best practices or where I should go to find best practices; so far google has not been very helpful/consistent on this topic.
More specifically, should I be thinking about writing a JCA connector for cassandra? Using a singleton EJB that talks to cassandra via Pelops? Just use pelops directly in my EJBs? (though I thought your not supposed to create socket connections in ejbs) Something else entirely?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
EJB 规范禁止 EJB 打开服务器套接字，但不禁止套接字。然而，它也禁止 EJB 创建线程。 Pelops（或 Hector）是否创建线程来处理其池化？
抛开法律条文不谈，由于这两个库都进行池化，所以对我来说它们绝对感觉像是属于资源适配器层的东西。我会对 EJB 感到紧张，它的生命周期由容器控制，并且可能非常短，依赖于像连接池这样的资源，其生命周期在某种程度上是独立的，并且应该更长。
也就是说，大多数 EJB 实现都是相当宽容的，因此无论直接从 EJB 使用 Pelops/Hector 在架构上是否正确，它都很可能会起作用。
如果我有足够的时间，我会编写一个资源适配器来包装这些库中的一个或另一个。然而，为了追求微乎其微的实际回报，这将是相当大的资源投入。
The EJB spec prohibits EJBs from opening server sockets, but not sockets. However, it does also prohibit EJBs from creating threads. Does Pelops (or Hector) create threads to handle its pooling?
The letter of the law aside, since both those libraries do pooling, they definitely feel like something that belongs in the resource adapter layer to me. I would be nervous about EJBs, whose lifecycle is controlled by the container, and is potentially quite short, hanging on to a resource like a connection pool whose lifecycle is somewhat independent, and should be longer.
That said, most implementations of EJB are quite forgiving, so whether the use of Pelops/Hector directly from EJBs is architecturally right or not, it is very likely that it will work.
If i had all the time in the world, i would write a resource adapter wrapping one or the other of those libraries. However, that would be a considerable investment of resources in pursuit of a negligible practical return.
我们正在开发一个类似的应用程序，我现在工作的地方，即使我们不实现 EJB，我们也会将后端部署到 Glassfish 3.1，并且在内部我们创建了一个与 Cassandra 对话的小型库。
目前，用于连接和使用 Cassandra 的最常用库是 Hector：
https://github.com/rantav/hector< /a>
它的开发非常活跃。我从未见过它在 EJB 中使用，但我使用过它，它非常可靠。但不知道 Pelops 是如何开发的。
我们在这里开发的是一个根据我们的需求定制的非常定制的应用程序，这就是我们一开始没有使用 Hector 的原因。
只要您在 EJB 中使用客户端套接字，就应该是安全的，EJB 的限制是针对应由应用程序服务器处理的服务器套接字。但如果您有其他需求，您应该编写您的 JCA。
we are developing a similar application where I work now, even if we do not implement EJB, we deploy a backend to Glassfish 3.1 and internally we have created a small library that talks to Cassandra.
Right now the most used library for connecting and working with Cassandra is Hector:
https://github.com/rantav/hector
It is very actively developed. I have never seen it in use inside an EJB, but I used it and it is very solid. Do not how Pelops is developed though.
What we have developed here is a very custom application tailored to our needs, that is why we didn't use Hector in the first place.
As long as you use client sockets in EJB, you should be safe, the restriction on EJB is for server socket that should be handled by the app server. But if you have other needs, you should write your JCA.