2

少し質問があります...ビーンのリモートインターフェイスでのみ宣言され、ローカルインターフェイスでは宣言されていないメソッドへのアクセスのローカルアクセスの違いを検索します...

インターフェイス宣言 (リモートまたはローカル) はメソッドのアクセス プロトコルを決定しますか? または、ejb コンテナーは、両方の Bean が同じ JVM を実行していることを認識していますか? 大きな性能差はありますか？これについてのソースはありますか？

BRの

ローラン

4

4 に答える 4

2

確かに、EJBコンテナでテストすることをお勧めします。

とはいえ、仕様（ここでは、セクション3.2.3）によれば、@ Remoteインターフェースは値によるパラメーターの受け渡しを使用する必要がありますが、@Localは参照によるパラメーターの受け渡しを想定しています。

つまり、クライアントと@Remote Beanの両方が同じJVM上にある場合でも、パラメーターのコピーのオーバーヘッドがあります。

また、すべての@Remoteパラメータがシリアル化可能である必要があることも意味します。

于 2009-07-26T11:58:40.373 に答える
1

はい、@Remote は常により多くの作業を行うため、@Local よりも常に遅くなります。

Bean のインターフェースを @Local と @Remote の両方として公開することの問題 (および仕様でそれがまれであると述べられている理由) は、パラメーターと戻り値のセマンティクスが明確でないことです。たとえば、メソッドがある場合:

List filter(List arg);

...そして、Bean が引数を変更してこのメ​​ソッドを実装する場合、クライアントは、メソッド (@Local) を呼び出す前にオブジェクトをコピーするか、オブジェクトが自動的に行われる場合は無駄にコピーしないように注意する必要があります ( @リモート)。さらに、Bean は、可変状態を @Local インターフェースから呼び出し元に渡さないように注意する必要があります。List の状況は明確かもしれませんが、java.util.Date のような疑わしい Serializable や、Bean が「定数」配列を返す必要がある場合は、それほど明確ではない可能性があります。

于 2009-07-28T05:18:57.213 に答える
0

ローカル インターフェイスなしで Bean を作成すると、同じ ejb コンテナー内の Bean はそのオーバーヘッドによって遅くなりますか? したがって、このローカル インターフェイスがリモート インターフェイスの「単なる」コピーであっても、ローカル アクセスがある場合は常にローカル インターフェイスを宣言することをお勧めします。

私は正しいですか？

あなたが言及したソース (JSR 220: Enterprise JavaBeansTM,Version 3.0 EJB Core Contracts and Requirements) では、「エンタープライズ Bean に対してリモート クライアント ビューとローカル クライアント ビューの両方を提供することは可能ですが、より一般的には 1 つまたはもう一方は提供されます。」

于 2009-07-26T13:50:51.410 に答える
0

私は自分のPCで、同じメソッドが宣言された2つのインターフェース（1つはローカル、もう1つはリモート）を試しました。

パッケージ計算; javax.ejb.Remote をインポートします。

@Remote パブリック インターフェイス CalculatorRemote {

public int add(int a, int b);
public int sub(int a, int b);

}

別の Bean では、両方のインターフェースを注入して使用します。

@EJB
public CalculatorRemote myRemoteCalc;

@EJB
public CalculatorLocal myLocalCalc;
public String fastest(int iter){
    myRemoteCalc.add(5,6);
    myLocalCalc.add(5,6);

    long inittimeLocal=System.currentTimeMillis();
    for(int j = 0; j<iter; j++){
        myLocalCalc.sub(28, 26);
        myLocalCalc.add(134778, 1234);
    }
    long LocalTime=System.currentTimeMillis()-inittimeLocal;

    long inittimeRemote=System.currentTimeMillis();
    for(int i = 0; i<iter; i++){
        myRemoteCalc.sub(28, 26);
        myRemoteCalc.add(134778, 1234);
    }
    long RemoteTime=System.currentTimeMillis()-inittimeRemote;

    if(LocalTime>RemoteTime){
        return "Local slower than Remote " + (LocalTime-RemoteTime) + " ms difference with remote processing in "+ RemoteTime + "ms and local processing in"+ LocalTime + " ms. ";
    }
    return "Remote slower than Local " + (RemoteTime-LocalTime) + " ms difference with remote processing in "+ RemoteTime + "ms and local processing in"+ LocalTime + " ms. " ;
}

メソッドを最速で呼び出すと (リモート呼び出しとローカル呼び出しのどちらが最速かを判断するために使用されます)、結果は 2 つのアクセス メソッド間で毎回 5 倍の時間係数を示します。

出力は次のとおりです。

200000回の反復で次の出力が得られました。

リモートはローカルよりも遅い 46,015 ミリ秒の差で、リモート処理は 58,609 ミリ秒、ローカル処理は 12,594 ミリ秒です。

および 100000 回の反復に対する次の出力: リモートはローカル 23 406 ミリ秒より遅い 29 609 ミリ秒のリモート処理と 6 203 ミリ秒のローカル処理との差。

および 1000 の次の出力

リモートはローカルよりも遅く、リモート処理は 297 ミリ秒、ローカル処理は 78 ミリ秒と 219 ミリ秒の差があります。

SUN が、彼が言及したセクションの最後で、Gregory のソースで 1 つのタイプのインターフェースのみを使用するようにほとんどアドバイスしているのは、非常に奇妙です 。 、より一般的には、どちらか一方のみが提供されます。

この場合、リモート アクセスのみでは通話が遅くなり、ローカルの高速アクセスの利点を誰も得られません。

どの Bean にも、リモート インターフェイスのメソッドを含むローカル インターフェイスが必要だと思います。リモート インターフェイス メソッドは、ローカル インターフェイス メソッドのサブセットになります。これにより、リモート クライアントは通常の方法で提供され、ローカル クライアントは高速な方法で提供されることが保証されます。

彼らは、内部と外部のものに異なる Bean を提供することを奨励するためだけに言っているのでしょうか? それとも、より複雑な方法では、ローカル アクセスとリモート アクセスが大きく異なるためでしょうか?

于 2009-08-02T14:18:49.333 に答える