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. |
||
|---|---|---|
| .. | ||
| plugins | ||
| bookshelf.js | ||
| index.js | ||
| listeners.js | ||
| utils.js | ||