Джерело
Затишна Галера | ЧарівнийКомпас 🧭2️⃣5️⃣4️⃣ Завдання 254Що таке optimistic locking і pes...
460 Охват/переглядів
2026-10-05 15:32
Повідомлення №3007
#ЧарівнийКомпас 🧭
2️⃣5️⃣4️⃣ Завдання 254
Що таке optimistic locking і pessimistic locking?
Це два підходи до вирішення ситуації, коли кілька користувачів або процесів одночасно намагаються змінити ті самі дані.
🤔 Optimistic locking виходить з припущення, що конфлікти трапляються рідко.
Система не блокує запис під час роботи з ним. Замість цього при збереженні вона перевіряє, чи не змінив хтось дані після того, як ми їх прочитали.
Типовий приклад - поле version.
Ми відкриваємо запис з version = 5, змінюємо його і намагаємся зберегти. Але якщо інший користувач уже встиг змінити цей запис і його версія стала «6», то наша операція буде відхилена через конфлікт.
Тобто логіка приблизно така: зроби додаткову перевірку перед збереження, навіть якщо це витратить ще трошки часу.
👍 Основні плюси тут: немає довгих блокувань,добре масштабується, підходить, коли одночасні зміни трапляються рідко.
😡 Мінус - конфлікт потрібно правильно обробити: повторити операцію, оновити дані або показати користувачу повідомлення.
🤔 Pessimistic locking працює навпаки. Система припускає, що конфлікт можливий, тому блокує ресурс заздалегідь.
Наприклад, одна транзакція читає рядок у базі та ставить lock. Інша транзакція, яка хоче змінити цей самий рядок, повинна чекати, поки блокування не буде знято.
Тут вже логіка наступна: поки один користувач працює з даними - інші поки що їх не змінюють.
👍 Основні плюси тут: менше ризику конфліктів під час запису, зручно для критичних операцій, де паралельна зміна небезпечна.
😡 Але і мінусів вистачає: інші операції можуть чекати, падає concurrency, неправильна робота з блокуваннями може призвести до deadlock.
Тобто основна різниця у підході - блокуємо ми дані чи ні, та надаємо можливість працювати з ними одночасно кільком користувачам чи ні.
@Zatishna_Galera
2️⃣5️⃣4️⃣ Завдання 254
Що таке optimistic locking і pessimistic locking?
Це два підходи до вирішення ситуації, коли кілька користувачів або процесів одночасно намагаються змінити ті самі дані.
🤔 Optimistic locking виходить з припущення, що конфлікти трапляються рідко.
Система не блокує запис під час роботи з ним. Замість цього при збереженні вона перевіряє, чи не змінив хтось дані після того, як ми їх прочитали.
Типовий приклад - поле version.
Ми відкриваємо запис з version = 5, змінюємо його і намагаємся зберегти. Але якщо інший користувач уже встиг змінити цей запис і його версія стала «6», то наша операція буде відхилена через конфлікт.
Тобто логіка приблизно така: зроби додаткову перевірку перед збереження, навіть якщо це витратить ще трошки часу.
👍 Основні плюси тут: немає довгих блокувань,добре масштабується, підходить, коли одночасні зміни трапляються рідко.
😡 Мінус - конфлікт потрібно правильно обробити: повторити операцію, оновити дані або показати користувачу повідомлення.
🤔 Pessimistic locking працює навпаки. Система припускає, що конфлікт можливий, тому блокує ресурс заздалегідь.
Наприклад, одна транзакція читає рядок у базі та ставить lock. Інша транзакція, яка хоче змінити цей самий рядок, повинна чекати, поки блокування не буде знято.
Тут вже логіка наступна: поки один користувач працює з даними - інші поки що їх не змінюють.
👍 Основні плюси тут: менше ризику конфліктів під час запису, зручно для критичних операцій, де паралельна зміна небезпечна.
😡 Але і мінусів вистачає: інші операції можуть чекати, падає concurrency, неправильна робота з блокуваннями може призвести до deadlock.
Тобто основна різниця у підході - блокуємо ми дані чи ні, та надаємо можливість працювати з ними одночасно кільком користувачам чи ні.
@Zatishna_Galera