2009-08-31 11 views
23

EJB 3 Beanからファイルシステムにアクセスするにはどうすればいいですか?EJB 3からファイルシステムにアクセスする方法は?

私はこの件に関してインターネットを検索しており、良い答えは見つかりませんでした。

この仕様ではこの使用が禁止されていますが、java.io/java.nioを使用することをお勧めします。とにかく、ほとんどのアプリケーションサーバーはこのAPIへのアクセスを許可しているようです。

もう1つの考え方は、JCAコネクタを使用してファイルシステムまたはLDAPディレクトリにアクセスすることです。

単純なファイルがパフォーマンスと使用されたリソースの点ではるかに優れたソリューションになる場合、データベースでBLOBを使用しないようにするにはどうすればよいですか。

どのようにこの問題を解決しますか?

+1

データベースにBLOBを持つ必要はありません。 SQL Server 2008では、ファイルをデータベースサーバーのフォルダにダンプしますが、データベースを介して公開します。 http://blogs.msdn.com/rdoherty/archive/2007/10/12/getting-traction-with-sql-server-2008-filestream.aspx – pjp

答えて

9

あなたはEJBの中のファイルシステムへのアクセスからを禁止している理由は、あなたのアプリケーションは、(JavaのEE)内で実行する方法を制御することはできませんということですコンテナ。たとえば、アプリケーションがサーバーのクラスター全体で実行されている場合、あるサーバー上のディレクトリーにオブジェクトを保存することはほとんど役に立たない可能性があります。 (もちろん、ネットワークファイルシステムを使用している可能性がありますので、制限が適用されない場合があります)。

1つのオプションは、使用あなたコンテナが付属していますJNDI実装であることができます。あなたはおそらく、あなたが常にオブジェクトの直列化形式を下に救うことができるので、いくつかのJNDIの場所で生byte[]配列を保存することができます:

ByteArrayOutputStream baos= new ByteArrayOutputStream(); 
ObjectOutputStream oos = new ObjectOutputStream(baos); 
oos.writeObject(myObj); 

//Now save into JNDI 
new InitialContext().bind("path/to/myobject", baos.toByteArray()); 

これは、後に見上げると、あなたのオブジェクトに再変換することができます。

byte[] bs = (byte[]) new InitialContext().lookup("path/to/myobject"); 
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bs)); 
MyObj myObj = (MyObj) ois.readObject(); 

代わりにあなたがJNDIにそれを保存するXML文字列として、あなたのインスタンスをエンコードするためにjava.beans永続XML(すなわちXMLDecoderXMLEncoder)を使用することができます。

+0

これは、EJBからファイルを書き込む推奨された方法ですか?ファイルはクラスタ内のすべてのノードで使用可能になりますか(JNDIは本当にクラスタ化されていると思われます) JNDIへの最後の読み込み(または書き込み)はトランザクション的ですか? –

+0

"あなたは許可されていません" - ファイルシステムへのアクセスはもはや許可されておらず、これはEJB仕様にのみ適用されることは決してありませんでした。当時それを書いた人は、EJBがJava EEのすべての基礎であり、そのためにJava EEとほぼ同等であることには惑わされていました。 –

7

アプリケーションをクラスタ化しない(またはドライブをネットワークマップできる)ことがわかっている場合は、java.io. *を使用してください。

ファイルストレージのルートの場所に関する適切な設定を必ず導入してください。

+0

+1この回答は単なる常識*です。ファイルが(EJBに準拠していない)別のプログラムで満たされている場合、それを行うための高速で明快な方法はありません。 – ATorras

+2

Java EE仕様に準拠していないアプリケーションを作成することで、ポータブルで保守可能であることを確認することはできません。たとえば、12ヶ月の時間で、このプロジェクトを後にしておき、アプリケーションをクラスタリングするタスクを与えられた貧しい人に大きな驚きを与えるかもしれません。または、別のコンテナに移植します。 –

+7

* "あなたはあなたのアプリケーションを集まらないことを知っているならば" * - あなたが将来見ることができると分かったら、ギャンブル業界でより有益なキャリアがあると考えるかもしれません。 –

5

ファイルデータへのアクセスをカプセル化します。次に、上で概説した方法のいずれかを使用することができます。データベースを使用することさえできます。システムのパフォーマンスを測定します。要件を満たしていれば、完了です。そうでない場合は、ファイルアクセスが1か所でローカライズされ、別のソリューションに置き換えることができます。ソフトウェアを別のコンテナに移植しなければならない場合や、他の人が管理しなければならない場合は、同じメリットがあります。

+0

カプセル化のために+1 – flybywire

1

プレーン・ファイル・アクセスは本質的にトランザクション性ではありません。トランザクション操作のサポートを構築していない限り(私は、これがどのようにリソースマネージャーの仕事なのか分かりません)、実行している操作のトランザクションの意味を心配する必要があります。トランザクションサポートを構築する場合は、パフォーマンスが低下する可能性はほとんどありません(データベースのパフォーマンスの低下の一部は、リソースマネージャによって行われたすべての簿記によるものです)。 そして、トランザクション管理の密な並行処理を忘れないでください。すべての要求に対して新しいファイルへの書き込みを開始しない限り、並行性の問題は多かれ少なかれあなたを苦しめます。

さらに詳しい情報はSun Blueprint's FAQ on EJB restrictionsにあります。

技術的に正当な理由がない限り、EJBからファイルシステムにアクセスしないでください。非常に良い例は、ロギング(監査ではない)のフレームワークです。ロギングはトランザクション操作である必要はないので、ファイルシステムへのアクセスに比較的害はありません。ログファイル。部分的な書き込みを受け入れることは許容されません。

+0

シングルトン/タイマーを介してファイルをローカルにキャッシュすることは、ほとんど常に安全な操作のもう1つの例です。 –

+1

"[...]あなたがEJBからファイルシステムにアクセスしようとしていない限り、" - これがEJBのためだけに保持される特別な理由はまったくありません。 EJB BeanであるBeanだけでなく、あらゆるタイプのBean *からIOを実行するときには注意が必要です。 –

関連する問題