- PR -

DBへの排他制御の方法について

投稿者投稿内容
なせ
常連さん
会議室デビュー日: 2006/01/06
投稿数: 41
お住まい・勤務地: おおさか
投稿日時: 2006-05-24 18:59
囚人さんへ
確かに完動する形でソースとか出したいのですが。。
もう4ヶ月あまりの時が経っているので
それがどこだったか。。って覚えて無いです。。
や、でもintとstringとかは比較てないことは確実です^^;

引用:

うにくまさんの書き込み (2006-05-24 18:24) より:
引用:

(==)とEqualsメソッドは必ずしも同じ結果では無いと記憶しています。。


いえ、同じはずです。等値演算子(=={op_Equality})の実装はEqualsメソッドを使用しています。


えーと一応確認の意味で
たとえば、int と longの1を比較した場合
(==)ではTrue
(equals)ではFalse
ですので、囚人さんの仰ってるように
String限定ってことですよね。
(==)は暗黙的に変換できるものは暗黙変換のもので比較
(equals)はオブジェクト自身を比較

引用:

(VBでは)Option Compare Textの場合、大文字と小文字が区別されないので、
期待する結果を得られなかったのでは?と思ったのですが、違うようですね。


そういう違いがあったんですね。。。
そのあたりも知りませんでしたね。。
#知らないことが多いなぁ(つд`)
#勉強になります('▽')ゝ
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2006-05-24 19:07
引用:

囚人さんの書き込み (2006-05-24 18:21) より:
その辺の記憶が曖昧になって「== と Equals が違う!」と言ってるのかな、と。


かいといてくれんと、そこまでよみとれへんよー。
釣られちゃったがなーww
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2006-05-24 19:27
だいぶ脱線気味ですが、本題に戻りつつ・・・
排他と言うとちょっと違うかもしれませんが、楽観的ロック、悲観的ロックの以外の方法として・・・。

・データベース(テーブル)の更新を一つのプロセスに委託する。一つのプロセスからしか更新を行わないので、当然排他処理も不要になる。データベースの更新を行うプロセスへの要求は、各クライアントから何らかの方法(ケースバイケース)で送る。

・トライ&エラー。テーブルへの制約条件やトリガーによって、不当な更新や追加がエラーとなる様にする。

と言う方法もあるかと。
日本海流
会議室デビュー日: 2005/08/12
投稿数: 14
投稿日時: 2006-05-24 20:48
> [思い切り取得(SELECT)して、
select 〜 for update no waitなどでロックして、

>コード(C#等の)上で比較(IF 〜)して、
>更新(UPDATE)
すれば如何でしょ。

Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-05-24 22:47
引用:

甕星さんの書き込み (2006-05-24 16:23) より:
コード:
UPDATE テーブル名 SET フィールド名 = {値}, 更新日付 = {現在時刻}
WHERE 更新日付 = {データ取得時の更新日付} AND ....その他の条件




更新日付の更新は、トリガでやらせています。コーディングする人に「こうやって更新してね」といって、その通りにしてくれるかわからないから。

って、更新日付のチェックを必ずしてくれるとも限らないのですけどね。
うにくま
ベテラン
会議室デビュー日: 2005/11/05
投稿数: 82
投稿日時: 2006-05-24 23:15
脱線したままで申し訳ないですが、確認への回答を。。。


引用:

なせさんの書き込み (2006-05-24 18:59) より:
int と longの1を比較した場合
(==)ではTrue
(equals)ではFalse
ですので、囚人さんの仰ってるように String限定ってことですよね。


同じですよ、値型もStringも
(==)は同値比較、
(Equals)は同型の同値比較、
です。
ただ、Stringには値型の様な異型の同値が存在しないだけです。

[ メッセージ編集済み 編集者: うにくま 編集日時 2006-05-24 23:17 ]
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2006-05-25 00:14
本題の方の話題ですが、楽観的ロックのキーとして最終更新日時を使うのは避けた方が良いです。

(0) 直前の更新
(1) セッションAがレコードを読み出し。
(2) セッションBがレコードを読み出し。
(3) セッションAが(1)のデータに基づいてレコードを更新。
(4) セッションBが(2)のデータ(1と同一)に基づいてレコードを更新。
という流れで、(0)〜(3)が同一時刻値に起こると、本来なら拒否すべき(4)の更新を受け入れてしまいます。

実例1
更新時刻の単位は秒。
webシステムだったので、秒単位で同一レコードが繰り返し更新されることはないと予測。
負荷テストのための自動ツールを複数動かしたら、見事に破綻(笑)。

実例2
更新時刻の単位はミリ秒。
同一レコードが1ミリ秒以内に繰り返し更新されることは性能上あり得ないと予測。
データベース代わりのスタブモジュールを使ったユニットテストで、排他制御関係が全滅(笑)

「上手くいかない可能性があるものは、結局上手くいかないのだ」という見本ですな。

以来、更新毎にインクリメントしていくカラムを持たせるようにしています。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2006-05-25 00:19
引用:

coasmさんの書き込み (2006-05-25 00:14) より:
実例1
更新時刻の単位は秒。
webシステムだったので、秒単位で同一レコードが繰り返し更新されることはないと予測。
負荷テストのための自動ツールを複数動かしたら、見事に破綻(笑)。

実例2
更新時刻の単位はミリ秒。
同一レコードが1ミリ秒以内に繰り返し更新されることは性能上あり得ないと予測。
データベース代わりのスタブモジュールを使ったユニットテストで、排他制御関係が全滅(笑)


安易に更新時刻を使うのがいいとは言いませんが、そもそもテストが間違ってるでしょう。
システムの想定(それも暗黙ではなく明確に想定したもの)を大幅に覆すテストに意味があるとは思えません。

※こういうテストの仕方もするので最初から避けておくという判断はまああるかもしれませんが。

スキルアップ/キャリアアップ(JOB@IT)