Optimistic locks

Даний підхід передбачає використання певного ключа (наприклад hash сума контенту файлу, до початку його редагування користувачем) при відправці відредагованого контенту файлу на backend сервіс. Під час збереження нового контенту файлу буде проводитись перевірка optimistic locking key, отриманого від користувача на відповідність файлу на файловій системі. Якщо ключ не відповідає файлу, то зміни користувача не будуть збережені і користувач отримає інформацію про це (http error code )

Використання в якості optimistic locking key дати останніх змін неможливе так як дата на файловій системі останньої зміни файлу буде завжди відрізнятися від актуальної дати зміни файлу одразу після git clone.
git optimistic lock

Pros

  • Не потребує додаткових інтеграцій з новими системами або компонентами

  • Не потребує зміни контракту структури git репозиторіїв на файловій системі

Cons

  • Потребує явної роботи з optimistic locking keys під час взаємодії з RestAPI (додає більше складність інтеграції з admin-portal backend service)

  • Потребує допрацювання існуючого коду admin-portal frontend