- PR -

インスタンスを跨いだ情報の共有

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-11-09 18:09
引用:

彷徨える開発者さんの書き込み (2004-11-09 17:20) より:
やはりDBに持つというのが正論でしょうか？

そうなると面倒なのがトランザクション。申込書の承認機能もあるので一度に複数の申込書をDBから持ってくる時があります。EntityBeanを申込書のデータ用と排他制御用を分けると片方を呼び出してもう片方を呼び出す間に他の人に割り込まれる可能性が有るのではないかと思います。

排他制御処理->データ取得の順番で常にやれば、割り込みが起こる可能性はないと思いますが。
それとも複数の申込書データをまず持ってくる、という仕様でしょうか。それでも、排他制御
部分のロックがきっちりできていれば問題ないでしょう。

ところでEntityBean(CMP?)必須でしょうか。排他制御用部分はJDBCでやる、というわけには
いかないでしょうか。それができるのであれば、以下のようなSQLを投げてやり、更新件数を
チェックすれば、申し込みデータ1件ごとであれば割り込みを受けずに排他制御ができると
思います。

UPDATE 排他制御テーブル SET 編集フラグ=TRUE WHERE キー=キー値 AND 編集フラグ=FALSE
彷徨える開発者
常連さん
会議室デビュー日: 2004/07/15
投稿数: 31
投稿日時: 2004-11-09 20:21
引用:

ukさんの書き込み (2004-11-09 16:23) より:
設計はキチンと考える必要がありますが、データベースに制御情報を持つのが確実でしょう。


この排他制御情報を管理しているsingleton-objectをインスタンス間でレプリケートする方法はないんでしょうか？であれば現状のロジックはほぼ流用できるのですが。(超甘？)

DBに持ち変えるとかなりの改造量になりそうです。JBOSSにはオブジェクトをレプリケートできる機能があるとかいうのをどこかで見たような記憶があります。
シュン
ぬし
会議室デビュー日: 2004/01/06
投稿数: 328
お住まい・勤務地: 東京都
投稿日時: 2004-11-09 20:47
引用:

この排他制御情報を管理しているsingleton-objectをインスタンス間でレプリケートする方法はないんでしょうか？であれば現状のロジックはほぼ流用できるのですが。(超甘？)

DBに持ち変えるとかなりの改造量になりそうです。JBOSSにはオブジェクトをレプリケートできる機能があるとかいうのをどこかで見たような記憶があります。


そのためだけにセッションレプリケーションを使うのは、重すぎかと思います。
それを行うEJBを作成するのが簡単と、インギさんが何度も言っているようですが…

1.複数のAPサーバで共有するEJBサーバを決めます。
2.上記EJBサーバに、そのSingleton-Objectへの問い合わせを行うEJBをデプロイします。
StatelessSessionBeanで十分です。SingleThreadModelなんかにしてしまうのがお手軽かも。
3.各APサーバは、Singleton-Objectへの問い合わせを行っていた処理を、上記のEJB
への問い合わせに変更します。

という感じですよね？
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-11-09 20:50
引用:

シュンさんの書き込み (2004-11-09 20:47) より:
そのためだけにセッションレプリケーションを使うのは、重すぎかと思います。
それを行うEJBを作成するのが簡単と、インギさんが何度も言っているようですが…

それだとクラスタ化した場合の冗長化構成ができないですよね?
彷徨える開発者
常連さん
会議室デビュー日: 2004/07/15
投稿数: 31
投稿日時: 2004-11-09 21:00
[quote]
ukさんの書き込み (2004-11-09 18:09) より:
引用:

排他制御処理->データ取得の順番で常にやれば、割り込みが起こる可能性はないと思いますが。
それとも複数の申込書データをまず持ってくる、という仕様でしょうか。それでも、排他制御
部分のロックがきっちりできていれば問題ないでしょう。


１件だけ排他する場合と複数件一度に排他する場合があります。
編集する場合は１件だけ排他しますが、承認の場合は検索条件(日付なり、起票者なりで)で検索してマッチしたものを排他制御します。

１件だけの場合は上のような処理でよいと思います。複数件の場合は検索条件でまず申込書のテーブルを検索しないと排他制御するキー情報(受付番号)がわかりません。従って、最初に申込書のテーブルを検索してから排他制御のテーブルに行追加という処理になります。
彷徨える開発者
常連さん
会議室デビュー日: 2004/07/15
投稿数: 31
投稿日時: 2004-11-09 21:09
引用:

シュンさんの書き込み (2004-11-09 20:47) より:
1.複数のAPサーバで共有するEJBサーバを決めます。
2.上記EJBサーバに、そのSingleton-Objectへの問い合わせを行うEJBをデプロイします。
StatelessSessionBeanで十分です。SingleThreadModelなんかにしてしまうのがお手軽かも。
3.各APサーバは、Singleton-Objectへの問い合わせを行っていた処理を、上記のEJB
への問い合わせに変更します。

という感じですよね？

なるほと、それもいい考えですね。
ただ、クラスタの場合は全てのクラスタのメンバでデプロイの内容は全て同じ(なはず)じゃないといけないですよね。
単にインスタンスを複数に分けた場合もこのStatelessSessionBeanをどこかのインスタンスにデプロイするとインスタンス間でデプロイの内容が違って管理が面倒かも。

この排他制御情報の専用の小さなインスタンスを立ち上げてそちらにデプロイするのがベターかな？
彷徨える開発者
常連さん
会議室デビュー日: 2004/07/15
投稿数: 31
投稿日時: 2004-11-10 10:38
引用:

シュンさんの書き込み (2004-11-09 20:47) より:
StatelessSessionBeanで十分です。SingleThreadModelなんかにしてしまうのがお手軽かも。


ところでStatelessSessionBeanのSingleThreadModelってどうやって実現するんでしょうか？StatelessSessionBeanのキャッシュの数(max-beans-in-free-pool)を1にすればいいんでしょうか？
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2004-11-10 11:49
>ただ、クラスタの場合は全てのクラスタのメンバでデプロイの内容は全て同じ(なはず)じゃないといけない
>ですよね。
クラスタ環境でも特定のモジュールを単一のサーバにデプロイすることはできますよ。
よほど負荷の偏りが心配されない限りクラスタメンバのうちどれかにデプロイしてしまっても問題にはならないでしょう。

>ところでStatelessSessionBeanのSingleThreadModelってどうやって実現
SingleThreadModelってサーブレットの話ですよね？私も EJB では聞いたことありません。
また、一つの EJB に対するメソッドコールはかならずシングルスレッドで行われますので一つの EJB インスタンスに同時にあちこちからアクセスさせるのは危険です。同時に同じ EJB インスタンスに対してメソッドコールが行われると後から呼び出したクライアントには RemoteException が送出されます。
weblogic-ejb-jar.xml にて allow-concurrent-calls を true に設定すれば同時よびだしはできますが、実際の処理は直列化されますので負荷の高い処理だとパフォーマンスのボトルネックになる可能性があります。
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）