Многие примеры оптимистичного параллелизма относятся к обновлениям с помощью отметки времени или флага базы данных.
Однако я хочу обрабатывать оптимистичный параллелизм для INSERTS
Чтобы проиллюстрировать вот фальшивый сценарий:
Несколько пользователей могут вставить запись журнала одновременно, но разрешить только одну запись журнала на дату.
Без какого-либо контроля параллелизма, поскольку несколько пользователей могут создавать записи журнала, я могу получить несколько записей в один и тот же день.
Как предотвратить это на уровне приложения БЕЗ использования базы данных (т. Е. Ограничения уникального ключа базы данных)





Вы можете написать триггер «при вставке» для проверки содержимого таблицы, а затем отказаться от вставки, если ваши критерии не соблюдены. Это доступно для большинства СУБД.
Независимо от того, определяете ли вы явное ограничение уникального ключа, это именно то, о чем вы просите.
Вы можете написать блок IF в своем коде SQL, чтобы проверить наличие записи журнала с указанной датой.
Но явное ограничение уникального ключа даст лучшую производительность.
Верно - явное ограничение уникального ключа не требует транзакции. Харрисон, используй правильный инструмент для работы :)
... но IF должен быть в транзакции на правильном уровне изоляции (возможно, Serializable).