回答編集履歴
4
文章校正
answer
CHANGED
|
@@ -10,7 +10,8 @@
|
|
|
10
10
|
実装・設計に関する部分でコメントします。
|
|
11
11
|
デフォルトのロック機能（読み込みは共有ロック、書き込みは排他ロック）のもと、DBのAtomicity特性に依存してテーブル設計、アプリケーション設計するのが一般的です（例えば受注処理にて、最後の在庫引き当てでマイナスになったらロールバックするようなモデル）。
|
|
12
12
|
|
|
13
|
-
個別レコードの排他ロックを制御するとなると、リトライ処理（タイマー持ちになると思いますが）などアプリケーションがトランザクション制御を担うことになります。もし自分であれば該当のトランザクションのみSerializable指定する方法を検討します。SQLServer+ADOであればIsolationLevelはトランザクション単位で指定可能です。その場合、Serializableとしたトランザクションのサイズ（レコード数・時間）が他の処理に影響しないものか評価が必要です。
|
|
13
|
+
個別レコードの排他ロックを制御するとなると、リトライ処理（タイマー持ちになると思いますが）などアプリケーションがトランザクション制御を担うことになります。もし自分であれば該当のトランザクションのみSerializable指定する方法を検討します。SQLServer+ADOであればIsolationLevelはトランザクション単位で指定可能です。その場合、Serializableとしたトランザクションのサイズ（レコード数・時間）が他の処理に影響しないものか評価が必要です。
|
|
14
|
+
|
|
14
15
|
---
|
|
15
16
|
「DBMSがトランザクションのACID特性を実現するための機能」を指すつもりで「トランザクション制御」という言葉を使いました。Oracle Masterではcommit文やrollback文をトランザクション制御文と呼称されていてアプリケーションがこれ等の文を発行することも「アプリケーションのトランザクション制御」に該当すると思います。まぎらわしい表現で済みませんでした。
|
|
16
17
|
文の意図としては、DBMSはトランザクションのACID特性を実現するために内部でリソース排他制御（リソース獲得、解放、タイムアウト監視）などの機能を実装していて、通常の（option無しの）SQL文の処理でも機能しています。なのでその上にAP側でも排他判定やタイムアウト監視を実装するのではなく、DBMS側の機能を利用する方向でデザインを検討されてはどうかというつもりでした。
|
3
コメントに対して補足
answer
CHANGED
|
@@ -10,4 +10,10 @@
|
|
|
10
10
|
実装・設計に関する部分でコメントします。
|
|
11
11
|
デフォルトのロック機能（読み込みは共有ロック、書き込みは排他ロック）のもと、DBのAtomicity特性に依存してテーブル設計、アプリケーション設計するのが一般的です（例えば受注処理にて、最後の在庫引き当てでマイナスになったらロールバックするようなモデル）。
|
|
12
12
|
|
|
13
|
-
個別レコードの排他ロックを制御するとなると、リトライ処理（タイマー持ちになると思いますが）などアプリケーションがトランザクション制御を担うことになります。もし自分であれば該当のトランザクションのみSerializable指定する方法を検討します。SQLServer+ADOであればIsolationLevelはトランザクション単位で指定可能です。その場合、Serializableとしたトランザクションのサイズ（レコード数・時間）が他の処理に影響しないものか評価が必要です。
|
|
13
|
+
個別レコードの排他ロックを制御するとなると、リトライ処理（タイマー持ちになると思いますが）などアプリケーションがトランザクション制御を担うことになります。もし自分であれば該当のトランザクションのみSerializable指定する方法を検討します。SQLServer+ADOであればIsolationLevelはトランザクション単位で指定可能です。その場合、Serializableとしたトランザクションのサイズ（レコード数・時間）が他の処理に影響しないものか評価が必要です。
|
|
14
|
+
---
|
|
15
|
+
「DBMSがトランザクションのACID特性を実現するための機能」を指すつもりで「トランザクション制御」という言葉を使いました。Oracle Masterではcommit文やrollback文をトランザクション制御文と呼称されていてアプリケーションがこれ等の文を発行することも「アプリケーションのトランザクション制御」に該当すると思います。まぎらわしい表現で済みませんでした。
|
|
16
|
+
文の意図としては、DBMSはトランザクションのACID特性を実現するために内部でリソース排他制御（リソース獲得、解放、タイムアウト監視）などの機能を実装していて、通常の（option無しの）SQL文の処理でも機能しています。なのでその上にAP側でも排他判定やタイムアウト監視を実装するのではなく、DBMS側の機能を利用する方向でデザインを検討されてはどうかというつもりでした。
|
|
17
|
+
それでもアプリケーション側の事情としてロック制御が必要なケースも有るかと思い、IsolationLevel変更の事例も書いてみました。質問３に関しては事例やアドバイスの収集が目的と思い、このような書きかたをしました。追加の回答はしないかも知れませんが、ご了承下さい。
|
|
18
|
+
|
|
19
|
+
XLOCKについては再現環境も無く追加情報は提示できませんが、行ロックにあたり対象の行がユニークでなければデッドロック要因ともなり得るのでその意味でPKが必要なのかもしれないと推測しました。
|
2
実装・設計に関する部分で補足
answer
CHANGED
|
@@ -5,4 +5,9 @@
|
|
|
5
5
|
```
|
|
6
6
|
|
|
7
7
|
実証はしていないのでご了承下さい。[参考にしたコンテンツ](https://qa.atmarkit.co.jp/q/248)です。
|
|
8
|
-
|
|
8
|
+
Isolation Levelも適切に設定する必要が有るかと思います。
|
|
9
|
+
|
|
10
|
+
実装・設計に関する部分でコメントします。
|
|
11
|
+
デフォルトのロック機能（読み込みは共有ロック、書き込みは排他ロック）のもと、DBのAtomicity特性に依存してテーブル設計、アプリケーション設計するのが一般的です（例えば受注処理にて、最後の在庫引き当てでマイナスになったらロールバックするようなモデル）。
|
|
12
|
+
|
|
13
|
+
個別レコードの排他ロックを制御するとなると、リトライ処理（タイマー持ちになると思いますが）などアプリケーションがトランザクション制御を担うことになります。もし自分であれば該当のトランザクションのみSerializable指定する方法を検討します。SQLServer+ADOであればIsolationLevelはトランザクション単位で指定可能です。その場合、Serializableとしたトランザクションのサイズ（レコード数・時間）が他の処理に影響しないものか評価が必要です。
|
1
IsolationLevelについて追記
answer
CHANGED
|
@@ -4,4 +4,5 @@
|
|
|
4
4
|
FROM 受注情報ヘッダ H WITH(ROWLOCK,XLOCK,NOWAIT)
|
|
5
5
|
```
|
|
6
6
|
|
|
7
|
-
実証はしていないのでご了承下さい。[参考にしたコンテンツ](https://qa.atmarkit.co.jp/q/248)です。
|
|
7
|
+
実証はしていないのでご了承下さい。[参考にしたコンテンツ](https://qa.atmarkit.co.jp/q/248)です。
|
|
8
|
+
IsolationLevelも適切に設定する必要が有るかと思います。
|