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

[TuMiki]

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 で
> 排他的にアクセスするのが現実的な回避策でしょうか．
> あまり簡単ではないですが．
> 
>