Базы данных. Конфликты параллельного доступа (Часть 1 — поиск проблемы)

[@Andrey_Rogovsky]

Эта проблема решается через диспетчер обращений, который являет собой надстройку над SQL с заданным алгоритмом поведения

[@sergei-grigorev]

данная статья описывает поиск проблемы, LINQ to SQL работает примерно таким образом, иначе как им узнать, была ли запись обновлена или нет?

[@vikds]

References:
Мартин Фаулер «Архитектура корпоративных программных приложений» (ozon)
Глава 16. Типовые решения для обработки задач автономного параллелизма
— Оптимистическая автономная блокировка (Optimistic Offline Lock)
— Пессимистическая автономная блокировка (Pessimistic Offline Lock)
— Блокировка с низкой степенью детализации (Coarse-Grained Lock)
— Неявная блокировка (Implicit Lock)

[@zerkms]

Думаю, что эта статья о CAS будет уместна здесь: www.ibm.com/developerworks/java/library/j-jtp04186/index.html

[@kemsky]

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

это не так, одна из транзакций упадет.

[@sergei-grigorev]

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

[@kemsky]

Это зависит от внутренней реализации механизма транзакций и используемого уровня изоляции транзакций. В случае mvcc описанный подход не работает, он приведет либо к потере обновлений либо к откату транзакции. Можете почитать здесь https://devcenter.heroku.com/articles/postgresql-concurrency. Нужно использовать явную блокировку lock или select for update.