Прийом 1. Фізична блокування як логічна блокування.

При взяття документа на редагування клієнтом можна одночасно
виконувати блокування запису (ів) у таблицях БД. І якщо блокування не
вдається, значить, цей запис заблокована іншим з'єднанням. За
завершення транзакції блокування сама знімається. Також у разі розриву
з'єднання, блокування буде знято.

Даний метод простий, надійний і навіть не вимагає написання великої
кількості допоміжного коду. Однак, даний метод створює велике
кількість труднощів для програм з великим документообігом, великим
кількістю одночасно працюючих користувачів, або в тому випадку,
коли додаток багаторівневе. Основним мінусом даного методу
є висока "ціна" за кожен заблокований документ, тому що потрібно
тримати транзакцію відкритою, а записи БД – заблокованими. І все
тільки задля обмеження доступу до документа. У випадку ж з WEB
додатками даний спосіб взагалі неприйнятний.

Тоді і зароджується ідея зробити не фізичну, а логічну
блокування.

Прийом 2. Проста захист від порушення цілісності даних.

Якщо вирішувати проблему тільки целостноті даних і взяти серйозну
обмеження, що тільки що відредагований документ може бути
втрачено, тому що його паралельно змінював інша людина, то завдання
можна помітно спростити. У цьому випадку добре застосуємо спосіб підфарбовування
документа останнім користувачем, що взяли його на редагування. У
таблиці (ах) заводиться додаткова колонка підфарбування. Коли
користувач бере документ на редагування, в спеціальну колонку
заноситься деякий унікальний ключ (це може бути і штамп часу). Про
цьому ключі знає тільки клієнтську програму і запис в БД. Якщо цей
ж документ буде редагувати інший користувач, він занесе свій
ключ, видаливши старий. Відразу після занесення ключа транзакція заривається.
І ні яких ресурсів БД протягом редагування документа на клієнта не
витрачається. А головне, не потрібно наявності постійного з'єднання. За
завершення редагування, програма буде намагатися оновити документ з
ідентифікатором і тільки їй відомим ключем. Якщо раптом, інший
користувач почав редагувати або вже редагував цей документ, то
ключ буде змінено цим користувачем. Тоді оновлення не пройде, тому що
документ з парою значень: "ID", "ключ", не знайдеться в БД і транзакцію
доведеться відкотити. Не дуже гуманно, але дієво, і головне,
максимально економить ресурси. Однак при дуже великій кількості
користувачів, що працюють з однією групою документів, відбудеться параліч
системи: (.

Можливо, просто потрібен інший спосіб:).

 

Прийом 3. Смітник і сміттяр.

Це, мабуть, найпоширеніший прийом після фізичних
блокувань. Він дуже схожий на них. Перед тим, як взяти документ на
редагування, ми повинні запам'ятати ID документа, де-небудь у БД або на
середньому шарі. Коли наступний користувач спробує працювати з цим
документом, необхідно перевірити, чи не зайнятий цей ID, і якщо зайнятий –
заборонити працювати з документом. Коли користувач закінчить роботу з
документом, він повинен видалити запис ID зі списку заблокованих
документів.

На перший погляд все просто. Але, при найближчому розгляді, питань
виникає більше, ніж відповідей. По-перше, де гарантія, що всі
користувачі будуть при редагуванні заносити кудись цей ID? Під
друге, де гарантія, що всі будуть видаляти цей ID після
редагування? (Як бути у випадку зависань або просто програмних
помилок? З усіма буває:)).

Проблема не так складна за наявності сервера програми. Можна
організувати єдиний механізм роботи з документом і гарантувати
видалення ID в разі проблем з клієнтом. Але, так чи інакше, потрібно
підбирати сміття – це уявні ID незаблокованих документів. Коротше,
поклавши руку на серце, – це, звичайно, спосіб, але все ж далекий від
досконалості.

Прийом 4. Договір.

Що можна назвати основною проблемою прийому 3? Це збірка сміття. І
якщо у випадку з 3-х рівневої архітектурою це менш складне завдання, то
в випадку з 2-х рівневої, вона практично не можна реалізувати. Крім того,
прийом 3 неприємний для WEB рішень, оскільки взагалі не зрозуміло, як в цьому
випадку підбирати сміття.

Якщо витягти плюси з прийому 3 і спробувати усунути недоліки, то
можна запропонувати наступний витончений спосіб.

Клієнт укладає з сервером (середній шар, БД, WEB сервіси) ДОГОВІР про
недоторканності документа, де йдеться, що він, клієнт, зобов'язується в
зазначений термін завершити роботу з запитаним документом (ID), або
продовжити договір. Інакше контракт на даний документ буде анульовано.

У реалізації, наприклад, з БД це може означати наступне, перш ніж
буде запитаний документ, відкривається транзакція, яка перевіряє, чи немає
Чи активного договору на запитуваний документ. Якщо він є –
вибачте, доведеться чекати. Якщо його немає – зелене світло, ми укладаємо
договір на даний документ на розумне час (наприклад, 4 хв)! Це
значить, що рівно через чотири хвилини наш договір стане, не
дійсний. У ці чотири хвилини ми повинні відкрити нову транзакцію, і
зберегти документ, причому при збереженні договір повинен бути присутнім
і бути актуальним. Остання операція в цій транзакції – видалення
договору. Якщо користувачу не достатньо цього часу, то клієнт
подовжує договір, призначивши новий час його закінчення. Залишилося при
укладення нового договору додати маленький код, що видаляє всі
прострочені договори (так про всяк випадок, раптом якийсь із
клієнтів завис).

 

Ця схема мені здається привабливою. Залишилася лише одна проблема –
правильний вибір часу договору. Якщо інтервал занадто маленький –
договір доведеться постійно продовжувати. Занадто великий – доведеться чекати, в
разі зависання клієнта, поки не закінчиться термін договору. Тут одна порада:
це повинно або налаштовуватися, або взагалі мати інтелектом, і час
має визначатися динамічно (у разі WEB рішень).

 

Прочитавши книгу ". Net Remoting" (Скотт Маклін, Джеймс Нафтел, Кім
Вільямс, видавництво "Російська редакція", Москва 2003), я виявив, що
дана методика не нова. У System.Runtime.Remoting.Lifetime Namespace
є інтерфейс Isponsor, який реалізує точно таку ж логіку, але не в
рамках БД, а врамках додатки середнього шару з використанням. Net
Framework.

 

Резюме.

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

  1. Надійність
  2. Ресурсомісткість
  3. Простота реалізації

Важливо відзначити, що створення середнього шару завжди благотворно впливає
на вирішення проблем такого типу, поєднуючи перший і 2-е якість, а
використання. net допомагає впоратися і з третьою проблемою:).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*