Введение
Метод управления конкурентным доступом
Оптимистический контроль конкурентного доступа (OCC), также известный как оптимистическая блокировка, — это метод управления конкурентным доступом без использования блокировок, применяемый к транзакционным системам, таким как реляционные системы управления базами данных и программная транзакционная память. OCC исходит из предположения, что множество транзакций часто могут успешно завершиться, не мешая друг другу. В процессе выполнения транзакции используют ресурсы данных, не устанавливая на них блокировки. Перед фиксацией каждая транзакция проверяет, не были ли изменены данные, которые она прочитала, другими транзакциями. Если проверка выявляет конфликтующие изменения, транзакция отменяется и может быть перезапущена. Оптимистический контроль конкурентного доступа был впервые предложен в 1979 году Х. Т. Кунгом и Джоном Т. Робинсоном. OCC обычно используется в средах с низкой степенью конкуренции за данные. Когда конфликты редки, транзакции могут завершаться без накладных расходов на управление блокировками и без ожидания освобождения блокировок другими транзакциями, что обеспечивает более высокую пропускную способность по сравнению с другими методами управления конкурентным доступом. Однако, если конкуренция за ресурсы данных высока, стоимость многократного перезапуска транзакций существенно снижает производительность, и в этом случае другие методы управления конкурентным доступом могут оказаться более подходящими. При этом методы, основанные на блокировках ("пессимистические"), также могут демонстрировать низкую производительность, поскольку блокировки могут значительно ограничивать эффективный параллелизм даже при избежании взаимоблокировок.
Optimistic concurrency control (OCC), also known as optimistic locking, is a non locking concurrency control method applied to transactional systems such as relational database management systems and software transactional memory. OCC assumes that multiple transactions can frequently complete without interfering with each other. While running, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the data it has read. If the check reveals conflicting modifications, the committing transaction rolls back and can be restarted. Optimistic concurrency control was first proposed in 1979 by H. T. Kung and John T. Robinson. OCC is generally used in environments with low data contention. When conflicts are rare, transactions can complete without the expense of managing locks and without having transactions wait for other transactions' locks to clear, leading to higher throughput than other concurrency control methods. However, if contention for data resources is frequent, the cost of repeatedly restarting transactions hurts performance significantly, in which case other concurrency control methods may be better suited. However, locking based ("pessimistic") methods also can deliver poor performance because locking can drastically limit effective concurrency even when deadlocks are avoided.
Примеры
Страницы редактирования MediaWiki используют OCC. Bugzilla использует OCC; конфликты редактирования называются «столкновениями в воздухе». Фреймворк Ruby on Rails имеет API для OCC. Фреймворк Grails использует OCC в своих соглашениях по умолчанию. GT.M использует OCC для управления транзакциями (даже отдельные обновления рассматриваются как мини-транзакции). Microsoft Entity Framework (включая Code First) имеет встроенную поддержку OCC на основе бинарного значения временной метки. Большинство систем контроля версий поддерживают модель «слияния» для обеспечения параллельности, которая является OCC. Mimer SQL — это СУБД, которая реализует только оптимистический контроль параллельности. Google App Engine использует OCC. Поисковая система Apache Solr поддерживает OCC через поле версии. Поисковая система Elasticsearch обновляет свои документы с помощью OCC. Каждой версии документа присваивается порядковый номер, а новые версии получают более высокие порядковые номера. Поскольку изменения в документе поступают асинхронно, программное обеспечение может использовать порядковый номер, чтобы избежать перезаписи более новой версии старой. CouchDB реализует OCC через ревизии документов. Схема управления транзакциями колоночной СУБД MonetDB основана на OCC. Большинство реализаций программной транзакционной памяти используют OCC. Redis обеспечивает OCC с помощью команды WATCH. Firebird использует многопоколенческую архитектуру как реализацию OCC для управления данными. DynamoDB использует условное обновление как реализацию OCC. Kubernetes использует OCC при обновлении ресурсов. YugabyteDB — это облачная база данных, которая в основном использует OCC. Firestore — это NoSQL база данных от Firebase, которая использует OCC в своих транзакциях.