DB2とデッドロック

Oracleと違って、DB2を使ったアプリはデッドロックが多発するんだけどね

この後Stingerで多くの局面的な解決方法が機能追加された
この2003年のころほど致命的にはならない

SQLステートメント

• DECLARE CURSORのWITH HOLDオプション
• CLOSEカーソルのWITH RELEASEオプション
• SELECTのFETCH n ROWS ONLY
• SET CURRENT ISOLATION (V8.1FP2)
• SET LOCKTIMEOUT (V8.2)
• SET KEEP UPDATE LOCKS (V8.2)

レジストリー変数

• DB2LOCK_TO_RB=STATEMENT
  ロックタイムアウトを起こしたステートメントだけをロールバック
  
• DB2_RR_TO_RS
• DB2_NO_PKG_LOCK
• DB2_EVALUNCOMMITTED (V8.1FP4)
  条件に合致しない行のロックを取得しない
  
• DB2_SKIPPDELETED (V8.1FP4)
• DB2_SKIPINSERTED (V8.2.2)

2009年OracleはSunを買収し、
MySQLを合わせると事実上のシェアは50％を越えてしまっただろう

1人当たりの経常利益は市場占有率の二乗に比例するのだそうだ
OracleとDB2の市場占有率は2:1から3:1にまで広がった
てことは、開発予算は4:1から9:1にまで広がってると推測

丸山先生のAmazonのDynamoの解説

データをいつでも書き込み可能
エラーや並行するする書き込みロックで、
書き込みを拒否されることはない

2009年4月 DB2 9.7から分離レベル"Currently Committed"が追加され
さすがにダーティリードは不要になった
これでPostgreSQLのMVCCくらいにまで改善
しかし、更新されコミットされてない行にはX-lockがかかるため
更新トランザクションは従来の仕様どおりに競合

Expert Oracle Database Architecture 9i and 10g Programming Techniques and Solutions
Thomas Kyte/CHAPTER7 Concurrency and Multi-Versioning

READ COMMITED分離レベルにおいて
UPDATEが競合し、更新対象のレコードが
別のトランザクションによって更新されていた場合
Oracleは内部でトランザクションをリスタートする

このリスタートで、UPDATEはいったんロールバックされ
その後、SELECT FOR UPDATEを使って更新対象レコードにロックをかける
ロックに成功すると再度UPDATEを実行する

トリガー(before update on 表 for each row)を仕掛けておくと
Oracleが内部リスタートする様子を観察できる

SERIALIZABLE分離レベルでは
ORA-08177: can't serialize access for this transaction
が発生する