mirror of
https://github.com/TryGhost/Ghost.git
synced 2024-11-28 22:43:30 +03:00
022c8c8e69
refs https://github.com/TryGhost/Team/issues/1248 This is the underlying cause of the problems we've seen whilst handling Stripe webhooks. A transaction ensures that the operations are atomic, but not that they can run concurrently. If you have some code which does this, concurrently: 1. Starts a transaction 2. Reads a value 3. Changes the values 4. Ends the transaction Without applying the `FOR UPDATE` lock - you will have both sequenes read the same value at step 2. With the `FOR UPDATE` lock - one of the sequences will hang at step 2, waiting for the other transaction to end, at which point it will resume and read the _changed_ value. Because the `edit` method explicitly does a read followed by a write, we have also add the `FOR UPDATE` lock to this by default, to avoid any race conditions. This does however require that `edit` is called within a transaction. An issue here https://github.com/TryGhost/Team/issues/1503 considers running in a transaction by default. |
||
|---|---|---|
| .. | ||
| e2e-api | ||
| e2e-browser | ||
| e2e-frontend | ||
| e2e-server | ||
| integration | ||
| regression | ||
| unit | ||
| utils | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .jshintrc | ||