PKでのDELETE後INSERTでDEAD LOCKする問題事象のご説明

REPEATABLE READで、PKでのDELETE後INSERTでDEAD LOCKする 問題事象について

Transcript

1. PKでのDELETE後INSERTでDEAD LOCKする 問題事象のご説明 Kentoku SHIBA
2. - トランザクション隔離レベルREPEATABLE READ - 同じレコードをPKを指定して、同時にDELETEすると、一方は成 功し、もう一方はロック待ちとなる。 - DELETEに成功した方の接続で、削除したPKのレコードを INSERTするとDEAD LOCKになる。 問題事象
3. 接続1 接続2 start transaction 接続2は、pk=1のレコードロック取得時にLOCK待ちになる。 接続1は、INSERT INTENTION GAP LOCKのチェックで、接続2のGAP LOCKにより待たされるためDEAD LOCKとなる。 問題事象 start transaction delete from t1 where pk = 1; delete from t1 where pk = 1; LOCK待ちになる insert into t1 (pk) values (1); DEAD LOCKになる
4. - INSERT INTENTION GAP LOCK INSERTレコードのネクストキーに対して、GAP LOCK（INSERT INTENTION GAP LOCKを除く）もしくは、NOT GAPではないレ コードLOCKがある場合、LOCK WAITとなる。 このチェックを通過後、 INSERT INTENTION GAP LOCKは即 時解除される。 - 暗黙レコードLOCK このレコードに対してLOCKのチェックが行われる際に、NOT GAPのレコードLOCKとして実体化する。 INSERT時はINSERT INTENTION GAP LOCKでLOCK競合を 確認し、INSERT後は暗黙レコードLOCKによって競合を確認する。 INSERT時のLOCK（REPEATABLE READ）抜粋
5. INSERT時のLOCKの挙動を踏まえると、 以下のケースのいずれかに該当すれば、 INSERT INTENTION GAP LOCKのチェックを省略できる。 - INSERTするレコードに既に排他レコードLOCKを取得している。 （DELETE、UPDATEが行われた場合など） INSERT INTENTION GAP LOCKの省略の検討
6. - READ COMMITTEDが利用可能であるかを検討し、 READ COMMITTEDで、DELETE→INSERTを行う。 - 同一レコードに対する処理が同時に行われないように、追加の排 他制御を行う。 - リトライが可能であるかを検討し、リトライ処理を行う。 現時点での対応策