This question's explanation and your answers so far.
あるトランザクション処理は, ①共有領域から値を読み取り, ②読み取った値に数値を加算し, ③結果を共有領域に書き込む手順からなっている。複数のトランザクションを並列に矛盾なく処理するためには, トランザクション処理のどの時点で共有領域をロックし, どの時点でロックを解除するのが適切か。 時間（上から下へ進む） - 時点（a） - ① 共有領域から値を読み取り - 時点（b） - ② 読み取った値に数値を加算 - 時点（c） - ③ 結果を共有領域に書き込む - 時点（d）
The lock at point (a) is correct, but the release is at point (c), that is, before the write in (3). If the lock is released at point (c), another transaction can read the old value that is still in the shared area, and this transaction writes afterwards, so one of the two additions is lost (a lost update). The write is not protected, so this option is not appropriate.
正解 The correct answer is イ (lock at point (a), release the lock at point (d)). This process touches the shared area at two places, the read in (1) and the write in (3), and the addition in (2) is based on the value read in (1). In other words, the result is free of inconsistency only if the value read in (1) is guaranteed not to be changed by another transaction before it is written back in (3). The lock should therefore be applied just before the read in (1), that is at point (a), and released just after the write in (3), that is at point (d). In this way the sequence (1) to (3) becomes an indivisible unit of processing, and other transactions read the updated value only after point (d), so no addition is wiped out (a lost update). Conversely, if the locked range is narrowed even slightly, room is left for another transaction to break in between the read and the write.
The lock is at point (b), that is, after the read in (1), so the read is unprotected and several transactions may read the same old value. In addition, the release is at point (c), before the write in (3), so the write is not protected either. Both the read and the write fall outside the exclusive range, which makes this the least appropriate combination.
Releasing the lock at point (d) is reasonable, but the lock is applied at point (b), after the read in (1). Because the read between points (a) and (b) is unprotected, if two transactions read the same value and then each performs its addition and write, the value written later overwrites the earlier update and one of the additions disappears. The lock must be applied before the shared area is read.