Як запобігти умовам перегонів у веб-додатку?

Розглянемо веб-сайт електронної комерції, де Аліса та Боб редагують списки товарів. Аліса покращує описи, а Боб оновлює ціни. Вони починають редагувати віджет Acme Wonder одночасно. Боб закінчує перше місце і економить продукт новою ціною. Алісі потрібно трохи більше часу, щоб оновити опис, і коли вона закінчить, вона зберігає продукт своїм новим описом. На жаль, вона також переписує ціну зі старою ціною, яка не була призначена.

На мій досвід, ці питання надзвичайно поширені у веб-додатках. Деяке програмне забезпечення (наприклад, програмне забезпечення wiki) має захист від цього - зазвичай другий збереження не вдається "сторінка була оновлена ​​під час редагування". Але більшість веб-сайтів не мають такого захисту.

Варто зазначити, що методи контролера самі по собі є потоковими. Зазвичай вони використовують транзакції бази даних, що робить їх безпечними в тому сенсі, що якщо Аліса і Боб спробують зберегти в той самий момент, це не спричинить корупції. Умова перегонів виникає у зв'язку з тим, що Аліса або Боб мають несвіжі дані у своєму браузері.

Як ми можемо запобігти таким умовам гонки? Зокрема, я хотів би знати:

• Які прийоми можна використовувати? наприклад, відстеження часу останньої зміни. Які плюси і мінуси кожного.
• Що корисне для користувачів?
• У які рамки вбудований цей захист?

Вам потрібно "прочитати свої записи", а це означає, що перед тим, як записати зміну, вам потрібно прочитати запис ще раз і перевірити, чи є зміни, які відбулися до нього з моменту останнього його читання. Це можна зробити по полю (дрібнозернистий) або на основі часової позначки (грубозернистої). Поки ви робите цю перевірку, вам потрібно виключно заблокувати запис. Якщо ніяких змін не було, ви можете записати свої зміни та звільнити замок. Якщо запис тим часом змінився, ви припиняєте транзакцію, звільняєте замок і повідомляєте користувача.

Я бачив два основні способи:

1. Додайте часову позначку останнього оновлення сторінки, яку редагує використання, у прихованому введенні. Під час здійснення позначки часу перевіряється на поточну, і якщо вони не відповідають, її оновив хтось інший і поверне помилку.

   • pro: кілька користувачів можуть редагувати різні частини сторінки. Сторінка помилок може призвести до різної сторінки, де другий користувач може об'єднати свої зміни в новій сторінці.

   • con: колись великі зусилля витрачаються витрачені під час великих одночасних редагувань.

2. Коли користувач починає редагувати сторінку, заблокуйте її протягом розумного часу, коли інший користувач потім намагається редагувати, він отримує сторінку помилки і повинен чекати, поки блокування закінчиться, або перший користувач здійснить.

   • Pro: Намагання редагування не витрачаються даремно.

   • con: недобросовісний користувач може заблокувати сторінку нескінченно. Сторінка з пропущеним блокуванням може закінчитись, якщо не буде вирішено інше (використовуючи техніку 1)

Використовуйте оптимістичний контроль за сумісністю .

Додайте стовпчик versionNumber або versionTimestamp у відповідну таблицю (ціле число є найбезпечнішим).

Користувач 1 читає запис:

{id:1, status:unimportant, version:5}

Користувач 2 читає запис:

{id:1, status:unimportant, version:5}

Користувач 1 зберігає запис, збільшуючи версію:

save {id:1, status:important, version:5}
new value {id:1, status:important, version:6}

Користувач 2 намагається зберегти записаний ними запис:

save {id:1, status:unimportant, version:5}
ERROR

Hibernate / JPA може це зробити автоматично з @Versionприміткою

Вам потрібно підтримувати стан запису читання десь, як правило, в сеансі (це безпечніше, ніж у змінній прихованій формі).

Деякі системи реляційного відображення об'єктів (ORM) визначатимуть, які поля об’єкта змінилися після завантаження з бази даних, і побудують оператор оновлення SQL, щоб встановити лише ці значення. ActiveRecord для Ruby on Rails - одна з таких ОРМ.

Чистий вплив полягає в тому, що поля, які користувач не змінив, не включаються до команди UPDATE, що надсилається до бази даних. Люди, які одночасно оновлюють різні поля, не перезаписують зміни.

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