Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Оптимистическое управление параллелизмом ( OCC ) - это метод управления параллелизмом, применяемый к транзакционным системам, таким как системы управления реляционными базами данных и программная транзакционная память . OCC предполагает, что несколько транзакций часто могут выполняться, не мешая друг другу. Во время выполнения транзакции используют ресурсы данных без получения блокировок этих ресурсов. Перед фиксацией каждая транзакция проверяет, что никакая другая транзакция не изменила прочитанные данные. Если проверка выявляет конфликтующие модификации, фиксирующая транзакция откатывается и может быть перезапущена. [1] Оптимистическое управление параллелизмом было впервые предложено Х.Т. Кунгом и Джоном Т. Робинсоном.[2]

OCC обычно используется в средах с низким уровнем конкуренции за данные . Когда конфликты случаются редко, транзакции могут завершаться без затрат на управление блокировками и без ожидания транзакций для снятия блокировок других транзакций, что приводит к более высокой пропускной способности, чем другие методы управления параллелизмом. Однако, если конкуренция за ресурсы данных является частой, стоимость многократного перезапуска транзакций значительно снижает производительность, и в этом случае другие методы управления параллелизмом могут быть более подходящими. Однако методы, основанные на блокировках («пессимистические»), также могут обеспечивать низкую производительность, поскольку блокировка может резко ограничить эффективный параллелизм, даже если тупиковые ситуации избегаются.

Фазы оптимистичного управления параллелизмом [ править ]

Транзакции оптимистичного управления параллелизмом включают следующие фазы: [2]

  • Начало : запишите временную метку, отмечающую начало транзакции.
  • Изменить : прочитать значения из базы данных и предварительно записать изменения.
  • Проверка : Проверьте , могут ли другие операции модифицировали данные , что эта сделка использовала (чтение или письменные). Сюда входят транзакции, которые завершились после времени начала этой транзакции, и, необязательно, транзакции, которые все еще активны во время проверки.
  • Фиксация / откат : если нет конфликта, все изменения вступят в силу. Если есть конфликт, разрешите его, обычно путем прерывания транзакции, хотя возможны и другие схемы разрешения. Следует проявлять осторожность, чтобы избежать ошибки времени проверки на время использования , особенно если этот этап и предыдущий не выполняются как одна атомарная операция.

Использование Интернета [ править ]

Без гражданства характер HTTP делает блокировки неосуществимым для веб - интерфейсов пользователя. Обычно пользователь начинает редактирование записи, а затем выходит, не переходя по ссылке «отменить» или «выйти из системы». Если используется блокировка, другие пользователи, которые пытаются редактировать ту же запись, должны дождаться истечения времени блокировки первого пользователя.

HTTP действительно предоставляет форму встроенного OCC. Ответ на начальный запрос GET может включать в себя ETag для последующих запросов PUT, которые будут использоваться в заголовке If-Match. Любые запросы PUT с устаревшим ETag в заголовке If-Match могут быть отклонены. [3]

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

Примеры [ править ]

  • Страницы редактирования MediaWiki используют OCC. [4]
  • Bugzilla использует OCC; Конфликты редактирования называются "столкновениями в воздухе". [5]
  • Платформа Ruby on Rails имеет API для OCC. [6]
  • Платформа Grails использует OCC по умолчанию. [7]
  • Механизм базы данных GT.M использует OCC для управления транзакциями [8] (даже отдельные обновления рассматриваются как мини-транзакции).
  • Microsoft «s Entity Framework (включая Code-First) имеет встроенную поддержку для ОКК на основе двоичного значения временной метки. [9]
  • Mimer SQL - это СУБД, которая реализует только оптимистичный контроль параллелизма. [10]
  • Хранилище данных Google App Engine использует OCC. [11]
  • Apache Solr поисковая система поддерживает OCC через поле _version_. [12]
  • Elasticsearch поисковая система поддерживает ОКК с помощью атрибута версии. [13]
  • CouchDB реализует OCC через исправления документа. [14]
  • В MonetDB колонка-ориентированной системы управления базами данных Схема управления транзакциями «сек основана на ОКК. [15]
  • Большинство реализаций программной транзакционной памяти используют OCC. [ необходима цитата ]
  • Redis предоставляет OCC через команду WATCH. [16]
  • MySQL реализует OCC в конфигурации репликации группы. [ необходима цитата ]
  • Firebird использует архитектуру нескольких поколений как реализацию OCC для управления данными. [ необходима цитата ]
  • DynamoDB использует условное обновление как реализацию OCC. [17]
  • Kubernetes использует OCC при обновлении ресурсов. [18]

См. Также [ править ]

  • Блок сообщения сервера № Оппортунистическая блокировка

Ссылки [ править ]

  1. ^ Джонсон, Рохит (2003). «Общие проблемы доступа к данным» . Индивидуальный эксперт по проектированию и разработке J2EE . Wrox Press. ISBN 978-0-7645-4385-2. Архивировано из оригинала 8 октября 2011 года.
  2. ^ а б Х. Т. Кунг, Дж. Т. Робинсон (1981). «Об оптимистических методах управления параллелизмом» (PDF) . ACM-транзакции в системах баз данных.
  3. ^ «Редактирование Интернета - обнаружение проблемы с утерянным обновлением с помощью незарезервированной проверки» . Примечание W3C . 10 мая 1999 г.
  4. ^ Справка: редактировать конфликт
  5. ^ «Bugzilla: FAQ: административные вопросы» . MozillaWiki . 11 апреля 2012 г.
  6. ^ "Модуль ActiveRecord :: Locking" . Документация по Rails Framework .
  7. ^ «Объектно-реляционное отображение (GORM)» . Документация Grails Framework . Архивировано из оригинала на 2014-08-15.
  8. ^ «Обработка транзакций» . Руководство программиста GT.M UNIX Edition .
  9. ^ «Совет 19 - Как использовать оптимистичный параллелизм с Entity Framework» . Блоги MSDN . 19 мая 2009 г.
    • Большинство систем управления версиями поддерживают модель «слияния» для параллелизма, которая называется OCC.
  10. ^ «Параллелизм транзакций - Оптимистический контроль параллелизма» . Разработчики Mimer - Возможности . 26 февраля 2010. Архивировано из оригинала 21 марта 2013 года . Дата обращения 6 мая 2013 .
  11. ^ «Хранилище данных» . Что такое Google App Engine? . 27 августа 2010 г.
  12. ^ «Обновление частей документов» . Проверено 28 июня 2018 .
  13. ^ «Elasticsearch - Руководство - Index API» . Руководство по Elasticsearch . 22 марта 2012 г.
  14. ^ "Couchdb Wiki - Document_revisions" . Архивировано из оригинала 4 февраля 2017 года.
  15. ^ «Сделки - MonetDB» . 16 января 2013 г.
  16. ^ «Транзакции в Redis» .
  17. ^ «Работа с элементами и атрибутами - условные записи» . Дата обращения 2 ноября 2020 .
  18. ^ «Обзор API - операции с ресурсами» . Дата обращения 3 ноября 2020 .

Внешние ссылки [ править ]

  • Кунг, HT; Джон Т. Робинсон (июнь 1981 г.). «Об оптимистических методах управления параллелизмом». ACM-транзакции в системах баз данных . 6 (2): 213–226. CiteSeerX  10.1.1.101.8988 . DOI : 10.1145 / 319566.319567 .
  • Enterprise JavaBeans, 3.0, Билл Берк, Ричард Монсон-Хефель, глава 16. Транзакции, раздел 16.3.5. Оптимистическая блокировка, Издатель: O'Reilly, Дата публикации: 16 мая 2006 г., ISBN для печати 0-596-00978-X , 
  • Холлманн, Андреас (май 2009 г.). «Множественная изоляция: достоинства и ограничения» ( PDF ) . Множественная изоляция (что находится между пессимистической и оптимистической блокировкой) . 01069 Gutzkovstr. 30 / F301.2, Дрезден: Happy-Guys Software GbR. п. 8 . Проверено 16 мая 2013 .CS1 maint: location ( ссылка )[ постоянная мертвая ссылка ]