2011-10-25 4 views
1

私は単純なクライアント(JavaSE、スイング) - サーバ(Java EE、EJB、JPA)アーキテクチャを持っています。JPAクライアント/サーバーレプリケーション/同期フレームワーク

私はサーバー側のエンティティに対してクライアント側の "キャッシュ"を作成したいと考えています。たとえば、エンティティをダウンロードした場合、エンベデッドダービーDB(クライアント側のJPA)に保存しますので、次回、必要になったときに、クライアントは独自のDBを最初に検索し、そこからエンティティを取得できますネットワーク通信を節約する。 (単純なレプリケーション)

私の問題はエンティティのIDから始まります。クライアントとサーバーの両方で同じIDを持つのは実際の悪い習慣ですから、クライアントサイドIDとサーバーサイドIDのマッピングを保存する必要がありますエンティティの 私は非常に多くのentites(15〜20 ..)とそれらの間の関連を持っているので、問題は継続します。

    :サーバ通信(更新、マージ)に向かって、またはクライアント側に右ID-Sを配置

    は、いくつかの多分再帰反射コード、マップされたID-Sのトラッキングを保持するエンジンを有するように促進します

  • クライアントサイドのエンティティを変更してサーバーに送信する前に、サーバーに送信する前に、エンティティセット内のクライアント側ID(さまざまな@OneToMany外部キー)を置き換える必要があります。
  • サーバー側からは、問題は別のものです。

このようなフレームワークは誰でも知っていますか?特にJPAユーザーにとっては?または、実装のヒントがあるかもしれませんか?可能であれば は//私は、同じIDを使用しないで何を事前に

おかげで、 アンドラーシュリットル

答えて

0

私は最近、サーバーとエンティティを同期させ、それらをローカルDerby DBに保存しなければならないクライアントをコードしました。クライアントは、サーバーと同期する必要がある新しいエンティティを作成することもできます。さらに、クライアントとサーバーの両方で、同じエンティティクラス、DAOおよびサービスレイヤコンポーネントが使用されていました。私は、私が遭遇した問題と私の解決策を共有します。彼らが関係しているなら、彼らが助けてくれることを願っています

クライアントとサーバーで同じIDフィールドを使用しました。

あなたが持つ可能性のある問題の1つは自動生成キーです。私のサーバーキーは、MS SQL Serverデータベースで自動生成されました。私の主体には注釈が付けられました。

@Id 
@GeneratedValue(strategy = GenerationType.AUTO) 

私は、サーバーが持っている同じIDを使用する方法を必要と私の地元のDerbyデータベースにエンティティを同期初めて。

これを行うには、キーの直接入力を可能にするクライアント・アプリケーションにorm.xmlファイルを作成しました。 orm.xmlは注釈をオーバーライドします。

参照:上記のリンクではもちろんSequence Generator in persistence.xml

、私は、ローカル・データベースのためのカスタムジェネレータを指定しました。 IDフィールドは自動生成がないものとして指定します。

私は新しいエンティティを作成していたので、クライアント上にジェネレータが必要でした。この場合、私は新しいキーを生成し、エンティティをサーバから挿入する方法が必要でした。 JPAプロバイダとしてHibernateを使用しました。これにより、エンティティが新しいかどうか、またはすでにIDがあるかどうかを把握したリスナを作成することができました。それに基づいて、私は生成器にIDを作成させるか、または既にそのIDが使用されているIDを使用しました。

参照:JPA ID Generation Strategy

次の私は、サーバーが新しく追加されたどのような実体を知るための方法を必要としていました。上記のリンクから、私の発電機が100000000で始まったことがわかります。の場合、この数値はサーバーが長い間(もしこれまでにないほど)高いIDを持たないため十分です。もちろん、それは最もクリーンな解決策ではなく、クライアント上のすべてのIDに負の数を使用しようとしましたが、Hibernateはバグのためにシーケンスを適切に作成しませんでした。

参照:JPA/Hibernate/Derby TableGenerator use negative values

は、だから私はそれらのいずれかが、マジックナンバー(100000000)の上にある場合は、すべてのエンティティが、来てチェックし、サーバー上で、私は保存する前に自分のIDをゼロ。このようにして、サーバーはそれらを新しいものとして追加し、サーバーからIDを取得します。その後、クライアントなどに同期させる必要があります。

+0

ヒントありがとうございます!何らかのフレームワークがあるかどうか、私の多くのネストされたエンティティに対してこのようなID処理ロジックを実装することをスキップすることができたかどうかは疑問でした。 –

+0

休止状態のリスナーは、すべてのエンティティで機能しました。エンティティがデータベースに保存されると実行されます。他の唯一のIDロジックは、クライアントからサーバーへの同期でした。おそらくリスナーを書くこともできます。そして、すべてが2つのクラスに含まれています。 – Allan

1

、アプリケーション・持続性レベルでこの問題を解決したいと思いますか?あなたが別のものを持っていないと問題がないようです...

+0

同じIDを使用した場合の基本的な問題は、オフラインでの可用性でした。クライアント側に新しいエンティティがある場合(例:サーバー接続はありませんが、クライアント側で最初にエンティティを格納する必要があるため、IDはクライアントDBから取得し、同期中にID-sをもう一度処理する必要があります。 –

関連する問題