Нужна ли нам блокировка уровня записи, если у нас уже есть транзакция для онлайн-заказа? (билета на концерт или бронирования авиабилетов)

Для онлайн-заказа мест на концерты или авиабилетов нам нужна блокировка уровня записи или транзакция достаточно хороша?

Для билета на концерт (скажем, место номер 20B) или билета на самолет (даже с овербукингом, ограничение составляет, например, 210), я думаю, что веб-сайт не может заблокировать какую-либо запись или начать транзакцию при отображении экрана покупки билета.

Но после того, как пользователь нажмет «Подтвердить покупку», сервер должен начать транзакцию, приобрести номер места 20B и попытаться зафиксировать.

Если другой пользователь уже купил Seat 20B в предыдущей транзакции, то это часть «Зафиксировать», что текущая транзакция завершится неудачно?

Итак... нам не нужна блокировка уровня записи? Всегда ли транзакции сериализуются (одна за другой), поэтому мы можем точно знать, что нет «состояния гонки»? В какой ситуации тогда необходима блокировка уровня записи?


database transactions rdbms record-locking
person nonopolarity    schedule 25.04.2010    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Перед вставкой строки вы можете проверить, где существуют записи с таким же SeatId. Если существует, откатите его, иначе вставьте строку и зафиксируйте. Я даже не Cofident, и я думаю, что если служба очень занята, вам, вероятно, потребуется блокировка перед началом операции вставки.

Однако есть второй интересный вариант.

Вы поддерживаете showId и seatId, чтобы сделать индекс с этими двумя. и создайте уникальное ограничение для этого индекса. Теперь запустите транзакцию с любой блокировкой. если дублирование существует. это, очевидно, потерпит неудачу из-за уникального ограничения. и фиксация будет неудачной.

Нил

person Neel Basu    schedule 02.07.2010