mirror of
https://github.com/TryGhost/Ghost.git
synced 2025-01-20 22:42:53 -05: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. |
||
---|---|---|
.. | ||
base | ||
relations | ||
action.js | ||
api-key.js | ||
author.js | ||
benefit.js | ||
custom-theme-setting.js | ||
email-batch.js | ||
email-recipient.js | ||
email.js | ||
index.js | ||
integration.js | ||
invite.js | ||
label.js | ||
member-analytic-event.js | ||
member-cancel-event.js | ||
member-email-change-event.js | ||
member-login-event.js | ||
member-paid-subscription-event.js | ||
member-payment-event.js | ||
member-product-event.js | ||
member-status-event.js | ||
member-stripe-customer.js | ||
member-subscribe-event.js | ||
member.js | ||
mobiledoc-revision.js | ||
newsletter.js | ||
offer-redemption.js | ||
offer.js | ||
permission.js | ||
post.js | ||
posts-meta.js | ||
product.js | ||
role.js | ||
session.js | ||
settings.js | ||
single-use-token.js | ||
snippet.js | ||
stripe-customer-subscription.js | ||
stripe-price.js | ||
stripe-product.js | ||
tag-public.js | ||
tag.js | ||
user.js | ||
webhook.js |