oura.a 9852004a36 Merged PR 636: ライセンス発行処理が遅い問題の解決およびトランザクションが効いてなければ効くよう修正する
## 概要
[Task3243: ライセンス発行処理が遅い問題の解決およびトランザクションが効いてなければ効くよう修正する](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/3243)

ライセンス発行処理が重複して実行できてしまう不具合を修正しました。
■修正内容
・ライセンス注文テーブルの情報を取得する際に、行ロックを取得するよう修正
・ライセンス注文テーブルに、「注文元アカウントID、POナンバー」の2カラムを対象とするインデックスを作成
・以前に外部キー制約をつけた際、自動で作成されていたインデックスを削除

■ロックについて
共有ロックと排他ロックがある
・共有ロック:共有ロック取得中でも、他のトランザクションが共有ロックを取得できる
       排他ロックは取得できない
・排他ロック:排他ロック取得中は、他のトランザクションは共有ロック・排他ロック共に取得できない
今回の修正では、デフォルト設定で共有ロックを取得していた箇所を、明示的に排他ロックを取得するようにした。

■行ロックについて
・インデックス行に対してロックをかけている
 →インデックスが作成されていない、検索条件にヒットしないなどでうまく動かない
  例)インデックスが作成されていないと、テーブル全体のロックとなってしまう
・上記の都合で検索条件が範囲指定のものにロックをかける際は注意が必要。(今回は一意指定なので問題なし)

■SQLiteを使ったユニットテストが`pessimistic_write`に対応していない件について
`process.env.NODE_ENV`の値を参照(テスト実行中は`test`、ビルドした環境で動かすと`undifind`)し、
テスト実行の場合`pessimistic_write`を付与しないようクエリを修正した。

## レビューポイント
インデックスについて懸念点があるか?

## UIの変更
なし

## 動作確認状況
ローカルで以下を確認
■発行処理について
・同じ注文に対し複数タブで発行処理を実行し、後発の処理が「ライセンス発行済みエラー」となることを確認
・同一アカウントからの異なるPOナンバーの注文を同時に発行し、行ロックによる待ちが発生せず並列に処理されることを確認
・別アカウントからの同一POナンバーの注文を同時に発行し、行ロックによる待ちが発生せず並列に処理されることを確認
■インデックスについて
同一アカウントからの異なるPOナンバーの注文を同時に発行
・インデックスを作成している状態で、行ロックによる待ちが発生せず並列に処理されることを確認
・インデックスを削除した状態で、行ロックによる待ちが発生することを確認
・migrate:up/downが正しく動作することを確認

## 補足
以前のアカウント削除PBIで一時的に設定した外部キー制約の作成時に、自動でインデックスも作成されていたようです。
必要ないインデックスはどこかで削除する必要があるかと思っています。
2023-12-27 02:01:24 +00:00
Description
No description provided
36 MiB
Languages
TypeScript 95.1%
HTML 1.9%
Shell 1.6%
SCSS 1.2%
Dockerfile 0.2%