Pessimistic locks

Даний підхід передбачає заборону (отримання lock) на зміну файлів в окремій директорії, якщо наразі інший користувач редагує будь-яку сутність в даній директорії.

git pessimistic lock
Адміністратори реєстру не взаємодіють з файловою системою як такою. Всі зміни відбуваються шляхом взаємодії з admin-portal backend service через RestAPI.
Технічна реалізація lock для файлів на файловій системі не розглядається в рамках даного документу

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

Область lock може бути технічно зменшена до окремих файлів на файловій системі.

Pros

  • Не потребує кардинальної зміни існуючого механізму взаємодії з git repositories

Cons

  • Потребує інтеграції з додатковим компонентом для збереження інформації про locks або розробки окремого контракту та механізму як зберігати дану інформацію на файловій системі (use transaction manager over Filesystem)

  • Потребує розробки механізму єдиного lock registry для декількох екземплярів admin-portal backend service