Пессимистическая и оптимистическая блокировка

Пессимистическая и оптимистическая блокировка

В 1980-е годы пессимистическая блокировка казалась хорошей идеей. В конце концов, простейший путь к решению проблем параллельного обновления – их распараллеливание. Если я редактирую файл, то вам лучше к нему не прикасаться. Система цветных кнопок, использованная нами в конце 1970-х, была своего рода механизмом пессимистической блокировки. Если файл был помечен кнопкой, то другие не должны были его редактировать.

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

Современные инструменты значительно лучше справляются со слиянием параллельно редактируемых исходных файлов. Ведь это нетривиальная задача: программа анализирует два разных файла и предка этих двух файлов, а затем применяет различные стратегии для определения способа интеграции параллельных изменений. И надо сказать, хорошо справляется с этой работой.

Так что время пессимистической блокировки прошло. Теперь нам не нужно устанавливать блокировку файлов при редактировании. Более того, вообще не нужно беспокоиться о блокировке отдельных файлов – мы запрашиваем сразу всю систему и редактируем нужные файлы.

Когда все будет готово к регистрации изменений, выполняется операция обновления. Она сообщает нам, не было ли более ранней регистрации изменений другими пользователями, выполняет автоматическое слияние большинства изменений, находит конфликты и помогает выполнить остальные слияния. После этого объединенный код регистрируется в базе.

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