Що робити, коли оптимістичне блокування не працює?

У мене такий сценарій:

1. Користувач робить GET запит до /projects/1та отримує ETag .
2. Користувач робить запит PUT до /projects/1ETag з кроку №1.
3. Користувач робить ще один запит PUT до /projects/1ETag з кроку №1.

Зазвичай другий запит PUT отримав би відповідь 412, оскільки ETag тепер застарілий - перший запит PUT змінив ресурс, тому ETag більше не відповідає.

Але що робити, якщо два запити PUT надсилаються одночасно (або рівно один за одним)? Перший запит PUT не встигає обробити та оновити ресурс до того, як прийде PUT №2, через що PUT №2 замінить PUT №1. Вся суть оптимістичного блокування полягає в тому, щоб цього не сталося ...

Механізм ETag задає лише протокол зв'язку для оптимістичного блокування. Служба прикладних програм відповідає за виконання механізму виявлення одночасних оновлень для забезпечення оптимістичного блокування.

У типовому додатку, який використовує базу даних, зазвичай це робиться, відкриваючи транзакцію під час обробки запиту PUT. Ви, як правило, читаєте існуючий стан бази даних всередині цієї транзакції (щоб отримати блокування читання), перевіряєте свою дійсність Etag та перезаписуєте дані (таким чином, що це призведе до конфлікту запису при будь-якій несумісній сумісній транзакції), потім здійснити. Якщо ви правильно налаштували транзакцію, один із комітетів повинен вийти з ладу, оскільки вони обидва намагаються одночасно оновлювати ті самі дані. Тоді ви зможете використовувати цю помилку транзакції або для повернення 412, або повторного запиту, якщо це має сенс для програми.

Ви повинні виконати таку пару атомно:

• перевірка дійсності тегу (тобто оновлена)
• оновлення ресурсу (що включає оновлення його тегу)

Інші називають це трансакцією - але принципово, атомне виконання цих двох операцій є тим, що заважає одній перезаписати іншу випадково; без цього у вас є умова перегонів, як ви відзначаєте.

Це все ще вважається оптимістичним блокуванням, якщо подивитися на велику картину: що сам ресурс не блокується початковим зчитуванням (GET) будь-яким Користувачем або будь-якими Користувачами, які переглядають дані, з наміром оновити чи ні.

Потрібна деяка атомна поведінка, але це відбувається в межах одного запиту (PUT), а не намагання утримувати блокування через кілька мережевих взаємодій; це оптимістичне блокування: об'єкт не заблокований GET, але все ще може бути безпечно оновлений PUT.

Існує також багато способів досягти атомного виконання цих двох операцій - блокування ресурсу - не єдиний варіант; Наприклад, легкої нитки або блокування об'єкта може бути достатньо і залежить від архітектури та контексту виконання програми.

Розробник додатків дійсно перевіряє E-тег і надає цю логіку. Це не магія, що веб-сервер робить для вас, оскільки він знає лише, як обчислити E-Tagзаголовки для статичного вмісту. Тож давайте візьмемо ваш сценарій вище та розберемо, як має відбуватися взаємодія.

GET /projects/1

Сервер отримує запит, визначає Е-тег для цієї версії запису, повертаючи його з фактичним вмістом.

200 - OK
E-Tag: "412"
Content-Type: application/json
{modified: false}

Оскільки клієнт тепер має значення E-Tag, він може включати це у PUTзапит:

PUT /projects/1
If-Match: "412"
Content-Type: application/json
{modified: true}

На даний момент у вашій заяві потрібно зробити наступне:

• Переконайтеся, що електронний тег все-таки правильний: "412" == "412"?
• Якщо так, зробіть оновлення та обчисліть новий E-тег

Надішліть відповідь про успіх.

204 No Content
E-Tag: "543"

Якщо з'являється інший запит і намагається виконати PUTподібний із вищезазначеним запитом, другий раз, коли ваш код сервера оцінює його, ви несете відповідальність за надання повідомлення про помилку.

• Переконайтесь, що електронний тег все-таки правильний: "412"! = "543"

У разі відмови надішліть відповідь про помилку.

412 Precondition Failed

Це код, який ви насправді повинні писати. Фактично E-тегом може бути будь-який текст (у межах, визначених у специфікації HTTP). Це не повинно бути числом. Це може бути і хеш-значення.

Як доповнення до інших відповідей я опублікую одну з найкращих цитат у документації ZeroMQ, яка правдиво описує основну проблему:

Щоб зробити абсолютно ідеальними програми MT (я маю на увазі це буквально), нам не потрібні мутекси, блокування чи будь-яка інша форма міжпотокового зв'язку, крім повідомлень, що надсилаються через розетки ZeroMQ.

Під "ідеальними програмами MT" я маю на увазі код, який легко написати і зрозуміти, який працює з однаковим дизайнерським підходом у будь-якій мові програмування та в будь-якій операційній системі, і це масштабує будь-яку кількість процесорів з нульовими станами очікування і без точки зменшення віддачі.

Якщо ви витратили роки на вивчення хитрощів, щоб змусити код МТ взагалі працювати, не кажучи вже про швидкі, із замками та семафорами та критичними розділами, вам буде огида, коли ви зрозумієте, що це все дарма. Якщо є один урок, який ми засвоїли за 30+ років одночасного програмування, це: просто не поділяй стан. Це як два п’яниці, які намагаються поділитися пивом. Не має значення, чи добрі вони. Рано чи пізно вони вступають у бій. І чим більше п'яниць ви додасте до столу, тим більше вони б’ються між собою за пиво. Трагічна більшість програм МТ виглядає як п'яні бари.