ПОСЛЕДСТВИЯ БЛОКИРОВКИ (LOCKING) в WEB-ПРИЛОЖЕНИЯХ

ВВЕДЕНИЕ

Область огромного интереса со стороны разработчиков заключена в том, как реализовать эффективную стратегию блокировки в web-приложениях.

Поскольку internet оперирует с протоколами, не обладающими определенным состоянием и постоянством, отсутствует концепция соединения (коннекции). Если нет коннекции, то нет способа сообщить, что пользователь продолжает использовать приложение.

Это становится проблемой там, где приложение является web-ориентированным и использует блокировку записей для управления приложениями в 'реальном времени'.

Данная статья предназначена для того, чтобы проиллюстрировать разницу между блокировками в терминальных приложениях «зеленого экрана» или клиент-серверных приложениях и блокировками в приложениях, выполняющихся через web.

БЛОКИРОВКА РЕАЛЬНОГО ВРЕМЕНИ И WEB

В приложении «реального времени» блокировка устанавливается на запись, если запись выбрана. Эта блокировка может оставаться, пока пользователь не закончит свою конкретную транзакцию, после чего пользователь может либо сохранить скорректированную запись, либо закрыть приложение (log out), завершая таким образом сеанс. Тогда запись будет освобождена.

Однако web-ориентированные приложения придерживаются «пакетной» модели, в которой пользователь запрашивает страницу, эта страница отображается, и коннекция прекращается. Нет понятия сеанса, который мог бы существовать за пределами запроса и возвращать страницу.

Также вполне вероятно, что пользователь может запросить одну страницу, а затем остановить работу приложения без выполнения процедуры 'закрытия сеанса’ - ‘logging off’.

В таких случаях web-приложению нельзя реализовать блокировку «реального времени» таким способом, который был бы возможен в терминальном приложении «зеленого экрана».

БЛОКИРОВКА WEB-ПРИЛОЖЕНИЙ

1. При реализации стратегии блокировки для web-приложения есть ряд подходов, которые можно применить.
2. Когда пользователь получает запись, делается копия информации. Когда пользователь сохраняет модифицированную версию записи, сравните копию с данными в файле. Если они не совпадают, то сохраненная запись была изменена после того, как пользователь получил эту информацию. Добавляется «штамп времени» - timestamp последнего обновления каждой записи. Когда пользователь сохраняет запись, сравните его с информацией в файле.
3.  

1. При получении записи внесите эту запись в файл ‘Record Locked’.  Когда пользователь сохраняет свои данные, удалите запись из файла.  Пока запись не сохранена, любой пытающийся получить запись будет проинформирован о том, что данная запись заблокирована и может быть получена как информация ‘read only’ – 'только для чтения'.  Поскольку есть вероятность того, что пользователь на самом деле никогда не выполнит сохранение информации, также может понадобиться функция таймера, постоянно проверяющая, когда будет освобождена запись. После заданного промежутка времени (например, 10 минут) блокировка будет освобождена.
2. Этот подход может быть улучшен для таких приложений, где редактирование записи может происходить на нескольких страницах, так что при навигации на другую страницу ь ходе редактирования для блокировки обновляется «штамп времени», чтобы убедиться, что блокировка не освобождена, пока пользователь продолжает редактировать запись.

4. Изменить способ работы приложения таким образом, чтобы оно не работало в реальном времени.

При подтверждении изменений необходимо информировать пользователей, что заказанный запрос получен и будет обработан позже. Обычно, если заказчик хочет заказать продукт через web, вряд ли он будет ожидать взаимодействия с базой данных в реальном времени.

Такие сайты, как WWW.AMAZON.COM и WWW.JUNGLE.COM, предоставляют свои сервисы подобным образом. Они указывают доступные предметы и объявляют, что заказанный предмет обычно ‘будет доставлен в течение суток‘ или ‘в течение Х дней’.

КОПИРОВАНИЕ И СРАВНЕНИЕ

Это не механизм блокировки как таковой, а скорее стратегия разрешения конфликтов. Идея в том, что там, где приложение может выполнить блокировку, вместо этого делается копия данных, которую можно будет модифицировать. Пример того, как это можно реализовать, подробно описан ниже в разделе BASIC.

В секции вашей программы, где происходит инициализация, объявите общий блок - common block для хранения данных, которые приложению нужно скопировать.

* Создаем named common для сохраненных записей

COMMON /Saved Records/Records(10)

Там, где обычно приложение делает блокировку, сохраните содержимое отдельно от переменных блока common. Ниже в примере показаны два файла, в которых обычно может делаться блокировка – это файл Employee и файл Department.

SUB edit (EmpID, DeptID)

* включаем сохраненные записи

COMMON /SavedRecords/Records (10)

  * Открытие файлов

CALL sysopen ("EMPLOYEE", employee, html)

CALL sysopen ("DEPARTMENT", department, html)

           * Читаем employee и делаем копию

READ emprec FROM employee, EmpID THEN

  Records (1) = emprec

END

* Читаем department и делаем копию

READ deptrec FROM department, Deptid THEN

  Records (2) = deptrec

END

         …и т.д.

По мере того, как приложение подходит к точке, где записи будут записаны назад в файлы, сохраненные копии сравниваются с текущим содержимым файлов. Если сохраненные значения совпадают со значениями в файлах, то приложение может без опаски записать новые значения.  Если же значения различаются – это показывает, что кто-то успел модифицировать файлы с тех пор, как была получена копия.

* включение блока сохраненных записей

COMMON /SavedRecords/Records (10)

* Читаем текущие значения из файлов

READ Curremp FROM employee, EmpID

READ Currdept FROM department, EmpID

* Были изменения?

IF Curremp = Records (1) AND Currdept = Record (2) THEN

  * Выполняем запись

WRITE emp ON employee, EmpID

WRITE dept ON department, DeptID

END ELSE

           *Здесь код для разрешения конфликта

  END

Если содержимое файлов изменилось, то приложение может много что сделать. В первую очередь, неплохо зафиксировать в журнале (log) факт, что где-то имел место конфликт.

После этого для приложения есть четыре возможных варианта действий:

1. Запись может продолжаться, как будто ничего не случилось.
2. Конфликт может быть представлен пользователю, а пользователь может решить, продолжать ли дальше или вернуться назад.
3. Конфликт может быть представлен пользователю, а приложение запретит выполнение записи.
4. Приложение может разрешить возникший конфликт исходя из набора бизнес-правил.

Очевидно, не все эти опции будут подходящими для каждого случая, и перед реализацией такой подход нужно оценить.

ОБНОВЛЕНИЯ СО «ШТАМПОМ ВРЕМЕНИ»

Опять же, это стратегия разрешения конфликтов. Идея состоит в том, что вместо блокировки приложение читает отметку времени последнего обновления из записи, которая будет модифицироваться.

Когда нужно сохранить запись, по «штампу времени» выполняется проверка, что со времени получения записи в оригинал не было внесено изменений. Если запись не менялась, то процесс записи продолжается как обычно.

Если какая-то из записей была изменена, то конфликт должен быть зафиксирован и разрешен таким же способом, как подробно описано в предыдущей секции.

БЛОКИРОВКИ ПРИЛОЖЕНИЯ

Написание полностью нового механизма блокировки потребует, возможно, наибольших усилий по сравнению со всеми описанными альтернативами, но даст максимальную степень гибкости.

Главная проблема для встроенного механизма блокировок состоит в излишней буквальности - блокировки записи абсолютны. Запись либо заблокирована, и остается такой пока не будет освобождена, либо не заблокирована.

Что требуется, так это механизм, способный назначить для записи блокировку, которая не сохраняется до явного освобождения, а снимается после определенного срока.  Таким образом, ресурс не сможет оставаться заблокированным навсегда, даже если пользователь просто отключит свой браузер.

Центральная часть нового механизма блокировок – необходимость где-то хранить эти блокировки. Для хранения всех блокировок приложения может использоваться один файл либо несколько отдельных файлов.

Когда приложению обычно нужно выполнить блокировку, оно сначала проверяет таблицу блокировок, чтобы убедиться, что кто-то другой не заблокировал запись. Предположим, что нет. Тогда приложение пишет отдельно в файл запись со следующей информацией:

• Filename
• Record Key
• TimeStamp
• Lock lifespan

Эту запись можно удалить одним из двух способов. Во-первых, когда приложение сохраняет обновленную запись, запись блокировки удаляется. Во-вторых, другая программа должна периодически читать таблицу блокировок и удалять записи тех блокировок, для которых истек срок действия.

Конечно, возможна ситуация, где срок жизни блокировки истекает до того, как приложение получит шанс записать обновленную запись. Если принять во внимание такую возможность, то неплохо будет комбинировать такую стратегию с одним из механизмов разрешения конфликтов.

Если в процессе обновления записи участвует несколько страниц, то блокировка может «освежаться» по мере того, как пользователь переходит со страницы на страницу.  В крайнем случае, для освежения блокировок в код можно включить периодическое подтверждение (submit).

ЗАКЛЮЧЕНИЕ

Если необходимость блокировки записей может быть полностью ‘оформлена при проектировании’, то проблема в целом будет снята. Однако достижение этой цели далеко не всегда настолько просто, как это звучит.

Чаще всего, если приложение показывает информацию, которую можно считать абсолютно актуальной – «живой», то пользователь будет ожидать «живой» реакции на изменение данных. Если такого отображения нет, то пользователь будет разочарован в своем представлении о природе системы, действующей в «реальном времени».

Чтобы помочь пользователю скорректировать свои ожидания, можно дать ему больше информации о том, как система будет работать. Сообщение о том, что все запросы будут обработаны в течение суток, сразу изменят ожидания пользователя, и он просто не будет ждать от системы немедленной реакции или ответа.

Обычно в примерах такого рода обновления записей выстраиваются в очередь и обрабатываются в пакетном режиме «за сценой». Пользователь вашего приложения после события получает извещение о том, что его запрос обработан успешно (или нет).

Если же web-ориентированное приложение должно предоставлять «живую» информацию, т.е. реагировать в «реальном времени», то следует использовать другие подходы.

Список литературы:

1. Мобильное программирование приложений реального времени в стандарте POSIX. Средства синхронизации потоков управления.- Интернет-университет информационных технологий - ИНТУИТ.ру, 2008.-http://www.intuit.ru/department/ hardware/resp/
2. Никифоров В.В. Операционные системы реального времени: Уч-метод. пособие. СПб.:Изд-во РГПУ. 2007. 109с.
3. Никольский О.Л. ПРОГРАММИРОВАНИЕ ПРИЛОЖЕНИЙ РЕАЛЬНОГО ВРЕМЕНИ ДЛЯ ИСПОЛНЕНИЯ В СРЕДЕ ОПЕРАЦИОННОЙ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ QNX/Neutrino 2 [Электронный ресурс]// Брянский государственный технический университет.-Режим доступа: http://www.swd.ru/files/pdf/nop/bgtu/BGTU_Posobie_pI-Slugba_vremeni.pdf (дата обращения 23.10.17)