[ главная ]   [ рейтинг статей ]   [ справочник радиолюбителя ]   [ новости мира ИТ ]



Ответов: 0
25-02-12 07:01







   Web - программирование
PHP


ASP






XML



CSS

SSI





   Программирование под ОС











   Web - технологии








   Базы Данных









   Графика






Данные




Базы Данных / Разное /

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

Когда два и более процессов должны последовательно работать с одними и теми же данными, например, два следующих одно за другим в одной программе 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, вы будете сталкиваться с одной и той же проблемой: отделение набора данных от всех других процессов и применение различный видов этих трех способов для его выполнения.





Комментарии

 Ваш комментарий к данному материалу будет интересен нам и нашим читателям!



Последние статьи: Базы Данных / Разное /

Разработка запросов
08-03-2010   

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

Кол. просмотров: общее - 4045 сегодня - 0

Параметрическое определение порядка сортировки данных
08-03-2010   

В различных сетевых форумах часто обсуждается вопрос: как получить отсортированные результаты выполнения запроса, передавая хранимой процедуре некоторый параметр? Я собрал несколько решений этой задачи, предложенных талантливыми программистами. Основная часть идей, изложенных в этой статье... подробнее

Кол. просмотров: общее - 4104 сегодня - 0

Delete from mytable; Commit:.. или Восстановление данных в СУБД Interbase
08-03-2010   

Данная статья написана на основе статей: The Interbase On - Disk Structure by Ann Harrison ; Structure of a Data Page by Paul Beach, а так же включает в себя мой горький опыт в удалении важных данных, а потом в их успешном восстановлении. Я никоим образом не собираюсь нарушать права ни выше перечисленных авторов, ни компаний, чьи зарегистрированные торговые знаки перечисленные в данной статье... подробнее

Кол. просмотров: общее - 4191 сегодня - 0

Часто задаваемые вопросы по базам данных
08-03-2010   

СУБД — Система Управления Базами Данных (dbms — database management system). Программа, либо комплекс программ, предназначенных для полнофункциональной работы с данными. Как правило, включает в себя инструменты для создания и изменения структуры хранения наборов данных... подробнее

Кол. просмотров: общее - 4650 сегодня - 1

Временные таблицы в sql server. Так ли необходимы временные таблицы?
07-03-2010   

Временные таблицы всегда прекрасно помогали разработчикам. Раньше, когда я использовал access, я обычно создавал временные таблицы, которые удалял после решения задачи. При использовании sql server решить задачу можно гораздо проще. Не так ли?... подробнее

Кол. просмотров: общее - 4231 сегодня - 1



  WWW.COMPROG.RU - 2009-2012 | Designed and Powered by Zaipov Renat | Projects