Comments 7
Эта проблема решается через диспетчер обращений, который являет собой надстройку над SQL с заданным алгоритмом поведения
References:
Мартин Фаулер «Архитектура корпоративных программных приложений» (ozon)
Глава 16. Типовые решения для обработки задач автономного параллелизма
— Оптимистическая автономная блокировка (Optimistic Offline Lock)
— Пессимистическая автономная блокировка (Pessimistic Offline Lock)
— Блокировка с низкой степенью детализации (Coarse-Grained Lock)
— Неявная блокировка (Implicit Lock)
Мартин Фаулер «Архитектура корпоративных программных приложений» (ozon)
Глава 16. Типовые решения для обработки задач автономного параллелизма
— Оптимистическая автономная блокировка (Optimistic Offline Lock)
— Пессимистическая автономная блокировка (Pessimistic Offline Lock)
— Блокировка с низкой степенью детализации (Coarse-Grained Lock)
— Неявная блокировка (Implicit Lock)
Думаю, что эта статья о CAS будет уместна здесь: www.ibm.com/developerworks/java/library/j-jtp04186/index.html
При пессимистичном подходе к параллелизму нет конфликтов, которые нужно решать, потому что база данных блокирована вашей транзакцией, так что никто другой не сможет её модифицировать у вас за спиной.
это не так, одна из транзакций упадет.
Ничего не упадет, вторая транзакция будет ждать пока вы отпустите данные, либо упадет, по истечении дедлайна. А он может быть установлен даже в несколько часов (лимит времени ожидания). Тут же не взаимоблокировка, поэтому на уровне сервера БД ему нет причины убивать какую-то из транзакций
Это зависит от внутренней реализации механизма транзакций и используемого уровня изоляции транзакций. В случае mvcc описанный подход не работает, он приведет либо к потере обновлений либо к откату транзакции. Можете почитать здесь https://devcenter.heroku.com/articles/postgresql-concurrency. Нужно использовать явную блокировку lock или select for update.
Sign up to leave a comment.
Базы данных. Конфликты параллельного доступа (Часть 1 — поиск проблемы)