Особенности паттернов параллельного программирования для бизнес приложений [PoEAA]

Спасибо за статью. Как раз думал над этой проблемой последние несколько дней. Мы используем Pessimistic Offline Lock уже несколько лет, но с увеличением нагрузки стало понятно, что дополнительная нагрузка на БД слишком большая, и процессы на разных серверах соревнуются за получение «замка». Решили использовать свой координационный сервер, которые будет выдавать токен доступа к данным в порядке поступления в очередь. Таким образом независимо от того кто и как манипулирует данными, весь код будет выполнен поочередно, а не хаотично.

Возможно стоит рассмотреть вариант с изменением задержек между попытками захвата блокировок. Длина задержки должна коррелировать со среднем временем удержания блокировки. Ну и механизм случайного изменения этой длины в нужном диапазоне. Первое может помочь в уменьшении накладных расходов соревнования за захват ресурса, а второе в более справедливом распределении. Конечно, если у вас нет особых требований к порядку выполнения.

Очень похоже на аналогию: критическая секция vs. CompareAndExchange-алгоритмы.

И обычно CompareAndExchange оказывается производительнее.