Как обычно, я думаю, что ответ зависит от характера бизнеса-приложений, которые вы строите. Каковы SLA для вашего приложения? Насколько это важно?
Если ваша инфраструктура обмена сообщениями не работает, приложение продолжает функционировать в стороне от службы блокировки? Если это так, то у вас, вероятно, есть обязательство убедиться, что ваш механизм управления параллелизмом не является единственной точкой отказа.
Кроме того, тема достижения действительно распределенного, отказоустойчивого пессимистического механизма блокировки требует обращения к problem of consensus. Большинство пессимистических алгоритмов блокировки полагаются на то, что существует единый, сериализованный орган, который может реагировать на запросы на блокировки (т. Е. Есть таблица блокировки или, возможно, есть сервер блокировки однопользовательской блокировки).
Такая конструкция имеет единую точку отказа, написанную на всем протяжении. Чтобы ответить на ваш первый вопрос - Да, я видел, как бизнес-приложения используют обмен сообщениями для обеспечения пессимистической блокировки. Однако полное решение проблемы отказоустойчивости кажется излишним для большинства бизнес-приложений, с которыми я столкнулся.
Оптимистичный контроль параллелизма не имеет этой проблемы по своей природе, поэтому он обычно предпочтительнее в распределенных, отказоустойчивых приложениях. Тем не менее, я понимаю, что бизнес-требования часто выигрывают от простоты внедрения.
Если эта тема вас интересует, Google опубликовал статью об их Chubby Lock Service, которая использует Paxos consensus protocol.