0

楽観的なアプローチの例では、@ version（たとえば、プロシージャのパラメータとして）は常に事前にわかっています。プロシージャで@versionを受信できるかどうか、およびそれが何に影響を与える可能性があるか。手順の一部：

CREATE PROCEDURE [dbo].[UpdateTestTable2]
...
SELECT @version = [version]
FROM dbo.TestTable2
WHERE Id = @Id

BEGIN TRANSACTION

UPDATE dbo.TestTable2
SET testName = @testName
WHERE Id = @Id AND [version] = @version
...
4

2 に答える 2

3

「バージョン」はアプリから取得する必要があり、更新用に選択されたレコードのバージョンを反映しています。次に、この情報は更新の一部として含まれ、「表示」されているのと同じバージョンのレコードを更新していることを確認します。

これは、外部（この場合は@id）からいくつかの情報を提供することによって行っているように見えます。ただし、Igorが指摘しているように、「バージョン」と呼ばれる列には魔法はありません。最初の選択を削除して、@idを使用してフィルターを終了できます。

しかし...不足しているのは、バージョン/IDフィールドの同時更新です。次のようなスモーシングを行う必要があります。

update testtable2
set versioning_column += 1
where versioning_column = @versioning_column

そうすることで、意図した列を正確に更新しますが、同時に、バージョンスタンプを変更することで、他の人が更新できないようにします。

于 2012-10-02T07:56:00.017 に答える
0

楽観的同時実行性を実装する簡単な方法は、データの読み取り時にハッシュ値を計算し、新しいデータを保存する前にこの値をテーブルに対して再計算することです。ハッシュ値が異なる場合は、読み取り操作と書き込み操作の間でテーブルが変更されます。

CREATE TABLE #TMP(name VARCHAR(10), age TINYINT);
INSERT #TMP VALUES ('Ann', 10);
INSERT #TMP VALUES ('Ann', 10);
INSERT #TMP VALUES ('Ann', 20);
INSERT #TMP VALUES ('Beth', 10);
SELECT *, CHECKSUM(*) AS [hashvalue] FROM #TMP

-- name       age  hashvalue
-- ---------- ---- -----------
-- Ann        10   940063178
-- Ann        10   940063178
-- Ann        20   940063188
-- Beth       10   1206720504
于 2012-10-02T09:05:22.877 に答える