Java EEでのCassandraの使用（GlassFish）

Question

現在、GlassFishにデプロイされているエンタープライズアプリケーションを作成しています。私は、GlassFish 3.1にデプロイされたEJB内からcassandraバックエンドに通信する正しい方法を理解しようとしています。私はPelopsを使ってCassandraと話すことを勧めます。

免責事項：私は、Java EEとエンタープライズアプリケーションサーバーとEJBの背後にある概念の初心者です。このプロジェクトの目的の1つは、これらのトピックを学ぶことです。これは、ベストプラクティスの正しい方向、またはベストプラクティスを見つけるためにどこに向かうべきかを指摘しているだけで、この質問の対象外です。これまでのところ、Googleはこのトピックについて非常に有用ではありませんでした。

具体的には、私はcassandra用のJCAコネクタを作成することを検討する必要がありますか？ Pelops経由でcassandraと通信するシングルトンEJBを使用していますか？私のEJBでpelopsを直接使用するだけですか？ （私はあなたがejbsでソケット接続を作成するはずではないと思っていましたが）何か完全に？

Answer 1

私が今働いているのと同様のアプリケーションを開発しています.Enterpriseを実装していなくても、Glassfish 3.1にバックエンドを導入し、内部的にはカサンドラと会話する小さなライブラリを作成しました。

今カサンドラと接続して作業するための最も使用されるライブラリは、ヘクターです：

https://github.com/rantav/hector

それは非常に積極的に開発しています。私はEJBの内部でそれを使用するのを見たことはありませんでしたが、私はそれを使用しました。ペロプスがどのように開発されていないか。

私たちがここで開発したのは、私たちのニーズに合わせた非常にカスタムのアプリケーションです。そのため、最初にHectorを使用しなかったのです。

EJBでクライアントソケットを使用する限り、安全でなければなりません。EJBの制限は、アプリケーションサーバーによって処理されるサーバーソケット用です。しかし、他のニーズがある場合は、JCAを作成する必要があります。

Answer 2

EJB仕様では、EJBがソケットではなくサーバーソケットを開くことを禁止しています。ただし、EJBがスレッドを作成することも禁止しています。 Pelops（またはHector）はプールを処理するスレッドを作成しますか？

これらのライブラリは両方ともプールされているので、法律上の手紙は別として、彼らは間違いなく私にリソースアダプタ層に属するもののように感じます。私は、ライフサイクルがコンテナによって制御されているEJBについては心配し、潜在的にはかなり短く、ライフサイクルがやや独立しているコネクションプールのようなリソースにぶら下がります。

EJBのほとんどの実装は非常に寛容ですから、EJBからのPelops/Hectorの使用が構造的に正しいかどうかにかかわらず、動作する可能性は非常に高いです。

私はいつも世界にいたとしたら、これらのライブラリのいずれかをラップするリソースアダプタを書きます。しかし、それは無視できる実用的な利益を追求するための資源のかなりの投資になるでしょう。