SELECT文でデッドロックになるパターン
PostgreSQL+Springを使用しているシステムにて、いくつかの特殊な状況が重なりデッドロックが発生した。
ざっくり言うと以下の順序で処理が発生した結果、デッドロックが発生。
- トランザクションAがSELECT * FROM user_attr;
- トランザクションBがTRUNCATE user_attr;
- トランザクションAを発生させたJavaプログラムが別のトランザクションCを発生させ、SELECT * FROM user_attr;
PostgreSQLのTRUNCATE周りの仕様
PostgreSQLのTRUNCATEはOracle/MySQLと違いロールバックが可能。
ただし、TRUNCATEの実行によりAccessExclusiveLockを獲得し、TRUNCATE実行中のSELECT文をブロックする。
PostgreSQLのSELECT仕様
SELECT文を実行すると、AccessShareLockを獲得する。
これはAccessExclusiveLock（=TRUNCATE）をブロックし、ブロックされるもの。
AccessShareLockは（ほかのロックもだけど）トランザクション終了まで保持し続ける。
Springにより１リクエスト当たり複数のトランザクションを発行するケース
TransactionalアノテーションのオプションであるPropagationの設定により、１リクエストの中で複数のトランザクションを発行する場合がある。
例えば業務処理Aと、ログ記録処理Bがあった場合、Aの結果に関わらずBをコミットした場合等に利用される。
今回はPropagation.REQUIRES_NEWを使用し、ログ記録処理を行っていた。
起こったこと
TRUNCATE実行時に、TRUNCATEが完了せず待ち状態に。
上記で言うところの業務処理A実行後、ログ記録処理B実行前にTRUNCATEが差し込まれた状態となり、デッドロック。
ロックの一端をJavaが握っている関係で、PostgreSQLのdeadlock_timeoutの検知が効かず、全てのリクエストがログ記録待ちでストップ。
対策
- そもそも運用中にTRUNCATEを使わない
- Propagation.REQUIRES_NEWを濫用しない。使う場合は通常のデッドロックにも注意が必要