1. начать транзакцию
2. выберите элементы в корзине покупок (с для блокировки обновления)

до сих пор так хорошо, это, по крайней мере, не позволит пользователю делать заказ в нескольких сеансах (несколько раз пытается проверить одну и ту же карту - хорошо иметь дело с двойными щелчками мыши.)

1. проверьте, если элементы не были забронированы другим пользователем

как вы проверяете? С стандарт SELECT или SELECT ... FOR UPDATE? Основываясь на шаге 5, я предполагаю, что вы проверяете зарезервированный столбец на элементе или что-то подобное.

проблема здесь в том, что SELECT ... FOR UPDATE на Шаге 2 не будет применяться FOR UPDATE блокировка ко всему остальному. Это только применение к SELECTed:cart-item таблица. Основываясь на имени, это будет другая запись для каждой корзины/пользователя. Это означает,что другие транзакции не будут заблокированы от продолжения.

1. произвести оплату
2. обновить элементы, помечая их как зарезервированные
3. если все прошло хорошо совершить транзакцию, откат в противном случае

следуя вышеизложенному, на основе предоставленной Вами информации, вы можете в конечном итоге несколько человек покупают один и тот же товар, если вы не используете SELECT ... FOR UPDATE на Шаге 3.

Предлагаемое Решение

1. начать транзакцию
2. SELECT ... FOR UPDATE в cart-item таблица.

это заблокирует двойной щелчок от запуска. То, что вы выбираете здесь, должно быть своего рода колонкой "корзина заказана". Если вы сделаете это, вторая транзакция приостановится здесь и дождется завершения первой, а затем прочитает результат, который первый сохранил в базе данных.

обязательно завершите процесс проверки здесь, если cart-item таблица говорит, что она уже заказана.

1. SELECT ... FOR UPDATE таблица, в которой вы записываете если товар был зарезервирован.

это заблокирует другие тележки / пользователей от возможности читать эти элементы.

в зависимости от результата, если элементы не зарезервированы, продолжайте:

1. UPDATE ... таблица на Шаге 3, пометив товар как зарезервированный. Сделайте любой другой INSERTs и UPDATEs вам нужно, также.

2. произвести оплату. Выполните откат, если платежная служба говорит, что платеж не работа.

3. запись платежа, если успех.

4. совершают сделки

убедитесь, что вы не делаете ничего, что может потерпеть неудачу между шагами 5 и 7 (например, отправка электронных писем), иначе вы можете в конечном итоге сделать платеж без его записи, в случае, если транзакция будет откат.

Шаг 3 является важным шагом в отношении того, чтобы убедиться, что два (или более) людей не пытаются заказать тот же предмет. Если два человека попытаются, 2-й человек в конечном итоге " зависнет "на своей веб-странице, пока он обрабатывает первый. Затем, когда первый закончит, 2-й прочитает столбец "зарезервировано", и вы можете вернуть сообщение пользователю, что кто-то уже приобрел этот элемент.

оплата в транзакции или нет

это субъективно. Как правило, вы хотите закрыть транзакции как можно быстрее, чтобы избежать блокировки нескольких людей от взаимодействия с база данных сразу.

однако в этом случае вы действительно хотите, чтобы они подождали. Вопрос только в том, как долго.

если вы решите совершить транзакцию до оплаты, вам нужно будет записать свой прогресс в какой-то промежуточной таблице, запустить платеж, а затем записать результат. Помните,что в случае сбоя платежа вам придется вручную отменить обновленные записи резервирования номенклатуры.

выбрать ... Для обновления несуществующего строки

просто слово предупреждения, в случае, если ваш дизайн таблицы включает вставку строк, где вам нужно раньше SELECT ... FOR UPDATE: если строка не существует, эта транзакция не заставит другие транзакции ждать, если они также SELECT ... FOR UPDATE несуществующей строки.

таким образом, убедитесь, что всегда сериализовать ваши запросы, делая SELECT ... FOR UPDATE в строке, которая, как вы знаете, существует первой. Тогда вы можете SELECT ... FOR UPDATE в строке, которая может существовать или еще не существовать. (Не пытайтесь сделать просто SELECT в строке это может существовать или не существовать, так как вы будете читать Состояние строки в момент начала транзакции, а не в момент запуска SELECT. Итак,SELECT ... FOR UPDATE на несуществующих строках все еще что-то нужно сделать, чтобы получить самую последнюю информацию, просто имейте в виду, что это не заставит другие транзакции ждать.)