Как избежать гоночных условий при продаже продуктов с JPA и Hibernate

Question

Как избежать гоночных условий при продаже продуктов с JPA и Hibernate

1

Я использую Java Spring Framework и Hibernate. Я делаю веб-приложение для электронной коммерции, где общественный пользователь может приобрести продукт из веб-приложения. Каждый продукт будет иметь количество.

вопрос

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

Workflow

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

Поэтому мой вопрос:

1) Я хотел бы подтвердить, что этот ответ на пессимистическую блокировку помогает решить мою проблему.

2) Хорошо ли работает мой рабочий процесс? Есть лучший способ сделать это?

CodeBender 11 апр. 2015, в 08:51

Источник

0

Это как раз та ситуация, для которой предназначено стандартное управление транзакциями.
chrylis 11 апр. 2015, в 21:48
0

Достаточно ли стандартной транзакции для решения проблемы? Я думал, что мне нужно применить блокировку. знак равно
CodeBender 12 апр. 2015, в 05:59

Теги:

java

hibernate

jpa

transactions

concurrency

1 ответ

Ещё вопросы

Это как раз та ситуация, для которой предназначено стандартное управление транзакциями.
Достаточно ли стандартной транзакции для решения проблемы? Я думал, что мне нужно применить блокировку. знак равно

Vlad Mihalcea · Accepted Answer · 2015-04-11T20-30-00.000Z

Вы также можете использовать оптимистичную блокировку и предотвращать возможные потерянные обновления.

С оптимистичной блокировкой, если два пользователя загрузили один и тот же объект со стеком одного, а один пользователь только что совершил покупку и уменьшил счетчик, тогда второй пользователь не сможет ОБНОВИТЬ продукт продукта, так как его версия продукта не соответствует той, которая найдена в базе данных (которая была увеличена первым пользователем).

При любом исключении (StaleStateException) текущая транзакция откатывается назад, и никакие изменения не применяются к базе данных (например, добавление OrderLine против продукта с нулевым количеством).

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

Спасибо! В случае второго пользователя, который пытается обновить измененное значение (первым пользователем), звучит ли правильно, если я просто повторю попытку? Повторить означает, что необходимо повторно подсчитать количество в новом сеансе и снова уменьшить его.
Я думаю, что безопаснее позволить пользователю повторить попытку вручную. Возможно, вы обновляли название продукта, и вы не хотите потерять это обновление. Только если вы переместите количество в сущность ProductStock, вы можете изолировать изменения количества и, следовательно, автоматически повторить транзакцию.