
### 概要

- JS forEach内部でawaitが使えなかった際に対処した備忘録

### 詳細

- LambdaからSQSにメッセージ送信する際に、[sendMessage](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SQS.html#sendMessage-property)関数をforEach内部で実行していた。
  - いざLambdaを動かすと、SQSにメッセージが送信されていなくて困った

### 対処法

- stackoverflowに書いてた
  - [https://stackoverflow.com/questions/37576685/using-async-await-with-a-foreach-loop](https://stackoverflow.com/questions/37576685/using-async-await-with-a-foreach-loop)
  - 代わりに `for...of` 内でawaitを使うと良いとのこと。

### 理由

- [Mozilla](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach#polyfill)に書いてあるが、`forEach does not wait for promises.`
- [qiitaの記事](https://qiita.com/frameair/items/e7645066075666a13063)でforEachのpolyfillを解説を見た。forEachはasyncではないのか。
- そのため、promiseの処理結果を待たずにイテレートする。
- Mozillaに載っているforEachでawaitが使えないコード例

```javascript
let ratings = [5, 4, 5];
let sum = 0;
let sumFunction = async function (a, b) {
  return a + b;
};

ratings.forEach(async function (rating) {
  sum = await sumFunction(sum, rating);
});

console.log(sum);
// Naively expected output: 14
// Actual output: 0
```


JSのforEach内部でawaitが使えない


## 概要

DB周りを再度学び直していて、トランザクションについて学びがあったのでまとめる。

## トランザクションとは？

複数のデータ更新処理を1つの単位にまとめたもの。
COMMITするとトランザクション確定させる。
ROLLBACKするとトランザクションを取り消す。

## 同時実行制御について

普段アプリケーションを通じて、自分以外の多くの人が検索 / 更新 / 削除など同時並行でトランザクションが実行されている。
この時、トランザクションの分離性（Isolation）を保つにはどうしたら良いのか？

- **トランザクションを直列に実行する**
  - ユーザーAのトランザクションCOMMITごにユーザーBのトランザクションを開始する形式
    - メリット
      - トランザクション分離性を保てるので、結果整合性を担保
    - デメリット
      - スループットの低下が顕著に
  - => スループットより結果整合性の方に重きを置いている。
- **ロックを使って並列に実行する**
  - 共有ロック / 排他ロックを使うことで、資源の占有 / 共有が可能になり、DBは並列に実行しながらある程度の分離性を担保できる

## ロックの問題点

- **スラッシング**
  - 並行して同じレコードに対してロックをかけようとするトランザクションが一定数超えると、1つのトランザクションが待機させられる頻度と時間が増え、スループットが低下すること。
- **デッドロック**
  - 複数のトランザクションが複数の資源をロックする場合、互いに相手の資源解放を待つ状態となり永遠にトランザクションが終わらない状態が続いてしまうこと。

## ロックの問題点を解消するには？

トランザクションの結果整合性を緩やかにしていく妥協策
=> 4つのトランザクション分離レベルという妥協策

- **非コミット読み取り（Read Uncommitted）**
- **コミット済み読み取り（Read Committed）**
- **再読み込み可能読み取り（Repeatable Read）**
- **直列化可能（Serializable）**

Serializableは結果整合性が強く担保されるが、それ以外は担保されないケースがある。
つまり、上3つを採用すると何かしらデメリットがある。
そのデメリットは下記の3つ。

- **ダーティリード**
  - トランザクションBでコミットされていないデータをトランザクションAで読み取ってしまう問題
- **ファジーリード**
  - トランザクションAでデータを複数回読み取っている途中で、トランザクションBでデータを更新してコミットした場合、トランザクションAで違う結果のデータを読み取ってしまう問題。
- **ファントムリード**
  - トランザクションAで一定の範囲のレコードに対して処理を行っている途中で、トランザクションBでデータを追加・削除してコミットした場合、トランザクションAで幻影のようにデータが反映されるため、処理の結果が変わってしまう問題

分離レベル毎に生じる問題をまとめると下記の表になる。
![テーブル](/images/transaction.png)

多くのDBMSがRead Committedを採用しているよう。

## 所感

DBMSは分離性をどう担保するかで苦労したんだろうな。


Kdevlog

JSのforEach内部でawaitが使えない

トランザクションについて整理する