- PR -

画面の排他処理について

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-08-04 11:32
どもです。がると申します。
んっと…脱線気味のネタなので、読み流していただければ。

引用:

今Tomcat５＆JSFでシステムの開発をしています。
そのシステムで画面単位で排他処理を行いたいらしく困っています。

なんかほかの場所でも同一のことを書いたような気がする
のですが :-P
基本的に上記の仕様は原理的には「無理」です。
理由は簡単で、

・画面排他のためには、画面openのほかに画面chage or 画面close
　を把握できなくてはいけない
・しかしHTTPは投げっぱなしプロトコルなのでopenとchageしか把握
　出来ない

ってな感じです。
やぱしほかのスレと同様の発言になってしまって恐縮
なのですが。
こういった設計そのものをきちんと「無理である」と伝えるほうが
ベターだと思うです。
# 会社組織だとそうもいかないのでしょうが、言うだけは言うほうが
# いいと思うです。

あと、
引用:

どういうことかというと、例えば「A画面」と「B画面」の画面は
Webなのにどっちか一つしか開けないという仕様です。
A画面を開いてる人がいたらB画面は開けない。逆もしかり。

この記述ですと
・誰かがA画面を開いていたら、ほかの人もA画面は開ける
・したがって「全員が」A画面を閉じない限りだれもB画面は使えない
という仕様に見えるのですが、それでよいのでしょうか？
# いあ、想定しにくい状況だったので(苦笑

ちっときびしくて根っこに触れる発言で恐縮ですが。
nak2k
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 86
投稿日時: 2005-08-04 14:58
＞がるがるさん
yu-ameさんの言われてる内容で実装すれば原理的に「可能」では？
画面closeをひろってる例としては、WEBメッセンジャーなんかがたぶんそうじゃないかと。

[追記]
closeを拾う、では誤解まねきますね。
ある画面を使用中であることを示すハートビートが途絶えたのを検知する、です。

[ メッセージ編集済み 編集者: nak2k 編集日時 2005-08-04 15:03 ]
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-08-04 15:33
どもです。がるです。

引用:

nak2kさんの書き込み (2005-08-04 14:58) より:
＞がるがるさん
yu-ameさんの言われてる内容で実装すれば原理的に「可能」では？
画面closeをひろってる例としては、WEBメッセンジャーなんかがたぶんそうじゃないかと。

「原理的」の部分の記述が甘くて誤解を招いている気がするです。
すみません。
私が「原理的に」というのは「HTTPプロトコルを基準に」という
意味になります。
で、HTTP基準で考えると「無理」です。
# 理由は省略。興味がある方がいて「書いて」といわれれば書きます。

引用:

[追記]
closeを拾う、では誤解まねきますね。
ある画面を使用中であることを示すハートビートが途絶えたのを検知する、です。

ですねぇ。で、この場合、厳密に考えると
・画面がcloseした「瞬間」はわからず、一定間隔で「画面が生きているか」をチェックするだけである
・ハートビートが途絶えた場合に「画面が閉じられた」のか「通信が死んでいる」のかが不明
などの制約事項が出てくるです。
一番目は、今回は多分問題にならないであろうと思うのですが。ただ、
一定間隔のハートビートって気をつけないと天然のDoSになりかねない
ので、サイト規模によっては注意が必要です :-P
二番目はもうちょっと深刻ですねぇ。短時間の通信異常を考えると、
数回くらいのハートビートなしは許容したいところなのですが。一方で
あまり多く許容すると「死んだのを検出するのに時間がかかる」ので。
バランスが難しいところです。

なので「概ねわかるであろう」ではあるのですが、根っこになるHTTPで
保証が無い以上「一定の制限が出てくる」のはやむをえないことで。
そのために、私は「原理的には無理である」と言ってます。
この辺をきちんとしないと、特に「わりとシビアだったりタイトだったり
する設計」の時に大変なことが起きてしまいやすいので :-P
さやべえ
常連さん
会議室デビュー日: 2003/03/13
投稿数: 33
投稿日時: 2005-08-04 16:02
こんにちは。さやべえです。
javax.servlet.HttpSessionAttributeListenerもしくは
javax.servlet.HttpSessionBindingListenerを使って対応できないでしょうか？
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2005-08-04 16:20
セッションのタイムアウトや破棄にたよると適切にログアウトせずウィンドウを閉じてしまった場合に不都合でしょう。
やはり XMLHttpRequest や隠しフレームをつかって特定のサーブレットに一定時間毎にアクセスしてロックを取得しつづけるような実装が確実ですかね。

本当に排他制御が厳密に必要であれば JavaWebStart や Applet の利用も視野に入れてはいかがでしょう。Socket プログラミングができますからよりシビアなタイミングでクライアントの死亡を検出できますね。

一番オススメなのは要求仕様の見直しですが・・・。

[ メッセージ編集済み 編集者: インギ 編集日時 2005-08-04 16:23 ]
nak2k
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 86
投稿日時: 2005-08-04 16:40
厳密な排他制御のためには「TCPコネクションを張りっぱなしにする」ことはやはり必須ですかね。。。
となるとあとは、HTTPを無理やり接続しっぱなしにするくらいかな？（レスポンスをゆっくりと行えば接続しっぱなしにできます。サーバリソースをその分占拠しますがそれはSocketを使用する場合も同じですし）

ただ、私も仕様の見直しが一番お勧めです^^;
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2005-08-04 17:02
>厳密な排他制御のためには「TCPコネクションを張りっぱなしにする」ことはやはり必須ですかね。。。
>となるとあとは、HTTPを無理やり接続しっぱなしにするくらいかな？（レスポンスをゆっくりと行えば接
ん、Tomcat には HTTP のコネクションが切れたタイミングを検出する仕組みがあるってことですか？
少なくとも標準の API ではないですよね。
ちょま吉
大ベテラン
会議室デビュー日: 2004/08/04
投稿数: 112
投稿日時: 2005-08-04 19:09
１つ疑問です。
セッションリスナーやハートビートですと
排他中に何らかの影響でAPサーバが突然落ちたり、サーバをメンテナンス等で再起動したり
した時は、DBに書き込まれたデータが宙ぶらりんになりませんかねー？
«前のページへ 1|2|3 次のページへ»

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