Базы данныхИнтернетКомпьютерыОперационные системыПрограммированиеСетиСвязьРазное
Поиск по сайту:
Подпишись на рассылку:

Назад в раздел

Три полезных способа блокировки.

Три полезных способа блокировки

Три полезных способа блокировки

Кейт МакЛеод
(Keith McLeod)

Когда два и более процессов должны последовательно работать с одними и теми же данными, например, два следующих одно за другим в одной программе SQL-предложения, таких как SELECT и UPDATE, то защита данных срабатывает в двух случаях: другие программы INSERT-ируют дополнительные данные или производят другие изменения, влияющие только на успешное выполнение предложений/процессов, а также при повторном запуске вашей же собственной программы. (Только, пожалуйста, не говорите мне, что этого не может быть.) Последнее – это подслучай разработчика, который надо понимать как особый случай. В каждом разе обоими процессами используется одна и та же блокировка, однако Reports Queries в палитре свойств не поддерживает атрибут FOR UPDATE.

Существует три основных способа решения этой проблемы: заблокировать таблицу и отругать пользователя (lock the table and damn the user ), использовать временную таблицу(ы) или использовать конструкцию SELECT FOR UPDATE-UPDATE-COMMIT. Какой из них лучше, зависит от обстоятельств; каждый предоставляет богатые возможности для такого излюбленного тактического отклонения, как Cascading Except-For.

Способ 1

LOCK TABLE...EXCLUSIVE - наиболее простое и легко выполнимое решение до тех пор, пока кто-нибудь по ошибке не выполнит COMMIT. Оно прекрасно подходит для ночной работы в тех системах, которые не рассчитаны на их использование в другое время, в системах, которые работают со слишком маленькими таблицами и выполняют краткосрочные задачи, или в небольших приложениях, когда необходимо два раза в месяц Зарегистрировать Заказы.

Один из возможных примеров: форма (Forms) выполняет LOCK TABLE, вызывает отчет (Report) (RUN_PRODUCT), а затем выполняет UPDATE и COMMIT. В этом случае должны быть выполнены два условия:

Form и Report должны использовать одну и ту же транзакцию. В Windows 3.1 это происходит по умолчанию, а в Windows 95 не поддерживается. (В документации указано, что оба системных параметра Reports, BATCH и BACKGROUND, должны быть установлены в значение "No".) В отчете не должна выполняться команда COMMIT. Откуда программа Forms может знать, что в вызванном отчете это не происходит и можно спокойно выполнять обновление? Так как Reports Server недоступен для Forms и RUN_PRODUCT не возвращает никаких значений, то Report обязан сам ВСТАВЛЯТЬ строки "begin" и "end" в некую журнальную таблицу, предназначенную специально для этого. Форма просматривает ее перед тем, как продолжить работу. Такая таблица очень полезна для слежения за процессом. (Слышали, должно быть, что-то типа "Оператор клянется, что она выполняла только Preview!"?) Любая программа должна где-то регистрировать свой запуск, записывать свои параметры и еще хоть что-нибудь писать в журнал аудита. Способ 2

Второй способ - это сделанная наспех версия первого: CREATE TABLE temp, LOCK TABLE source (или желательно, для большей наглядности, SELECT...FOR UPDATE), INSERT INTO temp FROM source, UPDATE source с таким же условием WHERE, как в INSERT, и COMMIT. Необходимые данные благополучно остаются сохраненными отдельно, а существующие данные соответствуют их измененному состоянию. Это можно осуществить с помощью хранимой процедуры, вызываемой из внешней программы, которая затем вызовет выполнение Report(s) над временной таблицей(ами). Отчеты могут делать с временными таблицами все, что им хочется, пока хранимая процедура не удостоверится, что они созданы так, как требуется.

В этом случае существует несколько потенциальных трудностей: задание временной таблице уникального имени, которое можно генерировать из ПОСЛЕДОВАТЕЛЬНОСТИ (SEQUENCE); размер имени, которое должно быть длиной не более 30 символов; надежность передачи имени временной таблицы только что запущенному экземпляру процесса; знание внешней программой, что процедура завершилась до вызова отчетов (см. выше). А также очистка временной таблицы после того, как подтвердится, что все необходимые действия с ее данными выполнены. У этого способа другие операционные запросы, но только он создает процессы, выполняющие их собственные соединения и поэтому использующие разные транзакции.

Способ 3

Это самый изящный способ, а это означает, что его также труднее всего поддерживать. (Вы знаете и других программистов, работающих над этим, которые моложе вас – но даже вам не всегда хватает опыта.) Он полезен только тогда, когда подмножество набора данных обрабатывается за один раз (суммируется, подсчитывается или обновляется), но не тогда, когда весь набор данных должен обрабатываться дважды, в этом случае вы возвращаетесь к блокировке таблицы, несмотря на использование SELECT...FOR UPDATE. Если во время работы процесса подмножество данных обрабатывается за один раз, то это решение использует самую быструю, наиболее отличающуюся от других схему блокировки.

Предположим, что ваша компания занимается торговлей и составляет отчеты по Заказам (Retailer’s Orders). Вы должны одновременно следить за курсом доллара всех Заказов (Retailer’s Orders) и изменять журнал регистрации Дебиторов (Receivables) каждого Продавца (Retailer) на такое же значение, как в отчете. В отчете первый запрос выполняется к таблице Продавцов; второй – к таблице Заказов. Первый запрос и группа возвращают только ID Продавца (и адрес или что-либо еще). SELECT...FOR UPDATE необходимо использовать для всех Заказов, которые попадают в заданный фильтр группы (фильтр группы можно задать в палитре свойств). Он срабатывает при возвращении каждой строки таблицы Продавцов и перед ее форматированием. Форматный фильтр для поля Общее Число Заказов (форматный фильтр можно задать в палитре свойств поля) может содержать оба предложения, и UPDATE, и COMMIT. Предполагается, что источник для этого поля – это столбец Сумма (Summary), определенный в группе Заказ (Order), и значение которого печатается и обнуляется только в конце каждого Заказа.

Можно было бы описать и другие проблемы проектирования и их решения, но эта статья - не докторская диссертация. Самая существенная из проблем проектирования - это необходимость перемещения данных из одной таблицы в другую, так как при этом изменяется статус таблиц. (Только в одной из программ необходимо для каждой группы строк выполнить SELECT...FOR UPDATE, INSERT таблица_назначения, DELETE исходная_таблица и COMMIT.) В простейшей форме можно, например, создать таблицу Заказов и таблицу Обработанных заказов вместо того, чтобы обновлять Заказы, изменяя столбец "Обработан", или по одной таблице для каждого состояния, в котором может находиться заказ. (Некоторые борцы за чистоту стиля подтверждают, что в этом случае не будет выполняться предложение UPDATE.)

Несмотря на то, что этот способ сокращает число проблем (и создает свои собственные затруднения), это гибрид 2 и 3 способа. До тех пор, пока необходимо выполнять последовательные процессы на одних и тех же данных, будут ли это две программы, два запроса в одной программе или SELECT и UPDATE, вы будете сталкиваться с одной и той же проблемой: отделение набора данных от всех других процессов и применение различный видов этих трех способов для его выполнения.

 



  • Главная
  • Новости
  • Новинки
  • Скрипты
  • Форум
  • Ссылки
  • О сайте




  • Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!
     Copyright © 2001-2024
    Реклама на сайте