[Seasar-user:14863] Re: [Teeda] 二重サブミットについて

TuMiki [E-MAIL ADDRESS DELETED]
2008年 6月 29日 (日) 09:49:58 JST


TuMikiです。
私の場合は、サーバー側の作りの問題でスティッキーにしました。
多重起動の解決をサーバー側で行うのでしたら、
クライアントに連続番号とサーバーのローカルアドレスを埋め込んで
確認する方法は使えないのでしょうか?

この方法だと、業務処理とは別にTeeda側で解決するかどうかは別として
記述できませんか?

select for updateは、更新に使いますが、
新規の場合には使えないし、シーケンスの番号が命だと無理があるとか、
アプリ開発者レベルのDBアクセスのやり方でマルチサーバーを考慮するっていう
のはなんだかつらい気がします。

サーバを分散した場合、この手の管理だけは共通でするようなEJBみたいな仕組
みを導入するのが本筋なのかもしれませんが・・・。

はずしてたら、すみません。

Koichi Kobayashi さんは書きました:
> 小林 (koichik) です.
> 
> Date:    Fri, 27 Jun 2008 21:00:06 +0900
> From:    松崎 学 <[E-MAIL ADDRESS DELETED]>
> To:      [E-MAIL ADDRESS DELETED]
> Subject: [Seasar-user:14855] Re: [Teeda] 二重サブミットについて
> 
>> 根本的な解決は出来ないという事ですよね。
> 
> 今回の件ということではなく,Teeda のスコープ
> 管理が正しく機能しないということです.
> 
>> 今回の修正で発生の確率がどのくらい低くなりますか?
>> ゼロではなくても、ほぼ発生しないのならばうれしいのですが。。。
> 
> 今回の件 (windowId の重複) に関してはほぼ発生しないと
> 思います.
> 
> それとは別に,同一セッションに対する複数の
> リクエストが異なったサーバで処理された場合に,
> あるサーバで行われたセッション情報の変更が
> 失われる可能性があるということです.
> どのくらいの可能性になるかは,同一セッションで
> 並行してリクエストが発生する頻度やサーバ側の
> 処理時間などに依存します.
> 
> スティッキーが使えない制約をどうにかするか,
> 大きなサーバで集中処理するなど検討する方が
> いいのではないかと思いますが,おそらく今更だと
> 思われるので,セッションを select 〜 for update で
> 排他的にアクセスするのが現実的な回避策でしょうか.
> あまり簡単ではないですが.
> 
> 


Seasar-user メーリングリストの案内