CICS - Обновления от нескольких пользователей

Question

Если около 50 пользователей пытаются обновить одно и то же поле в таблице DB2, как CICS справится с этим? Как это обрабатывается в программе DB2 COBOL?

Answer 1

В руководстве IBM, How CICS connects to DB2:

CICS® DB2® прикрепление объект снабжен CICS. Средство вложения CICS DB2 предоставляет приложениям CICS доступ к данным DB2 во время работы в среде CICS. Таким образом, приложения CICS могут обращаться к данным DB2 и данным CICS. CICS координирует восстановление данных DB2 и CICS, если происходит сбой или сбой системы.

Средство вложения CICS DB2 создает общее соединение между CICS и DB2. Приложения CICS используют это соединение для выдачи команд и запросов DB2. Соединение CICS и DB2 может быть создано или завершено в любое время, а CICS и DB2 можно запускать и останавливать независимо. Вы можете назвать отдельную подсистему DB2, к которой подключается CICS, или (если у вас есть DB2 Версии 7 или более поздняя версия), вы можете использовать средство группового присоединения, чтобы DB2 мог выбрать любого активного члена группы разделения данных подсистем DB2 для подключения. У вас также есть возможность автоматического подключения и повторного подключения CICS к DB2. Систему DB2 можно использовать несколькими системами CICS, но каждая система CICS может быть подключена только к одной подсистеме DB2 за раз.

На простом английском языке подумайте о том, что CICS имеет несколько пулов соединений для DB2.

Когда определена таблица DB2, она определяется как блокировкой страниц, так и строк. (Его можно определить с помощью блокировки таблицы, но это редко). Механизм базы данных DB2 не позволяет нескольким пользователям обновлять страницу или строку за раз, в зависимости от уровня блокировки.

Есть также блокировки чтения для поддержания согласованности таблиц. DB2 вызывает эти блокировки чтения isolation levels.

Answer 2

Некоторая необходимо соблюдать осторожность, чтобы чесотки целостности данных при CICS псевдо разговорные программы взаимодействуют с БД/2 для обновления базы данных, особенно когда несколько транзакций CICS может пытаться читать/обновить ту же DB/2 строки таблицы почти в то же время.

Далее следует очень упрощенное объяснение общей схемы проектирования для псевдодиагностических транзакций CICS (это наиболее распространенный тип шаблона интерактивного программирования для CICS). Ответы на этот вопрос: what-are-the-advantages-of-pseudo-conversational-vs-conversational-cics-programm обеспечивает краткий обзор того, как псевдо разговорные CICS работы, вы можете рассмотреть это прежде, чем продолжить ...

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

Блокировки DB/2 являются ключом к сохранению целостности базы данных перед лицом нескольких транзакций select/update/insert/delete, конкурирующих за с теми же строками базы данных.Проблема с псевдодиагностической CICS заключается в том, что эти блокировки теряются между моментом, когда транзакция захватывает свои данные из таблицы и время, необходимое для обновления таблицы.

Состояния, что сделка типичный псевдо разговорного CICS может пройти через что-то вроде:

• Начальная - Начать свежую сделку, задать пользователю ввести ключевые данные (установка следующего состояния в Display)
• Дисплей - Подтвердить ввод ключа, введенного на Исходный код Штат. Получить данные, связанные с БД/2 и вывести его (установить следующее состояние для Commit)
• Commit - Проверка измененных данных из дисплея состояния и обновление БД/2 (устанавливается следующее состояние для Initial)

Обратите внимание, что данные получены в течение Дисплей. Блокировка чтения выполняется DB/2 при этом времени для защиты от других транзакций от , обновляя строку при ее считывании. В зависимости от того, как настроены DB/2 и ваш DML , эта блокировка может быть активна только на протяжении фазы Дисплей или только при извлечении строки . В любом случае блокировка будет потеряна, как только программа выйдет. Когда программа снова запустится, она будет в Commit состояние готово к выполнить соответствующий DB/2 update/insert DML для выполнения запрошенных изменений в базе данных.

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

Общий механизм, используемый программистами для поддержания целостности данных в течение псевдо разговорной CICS сделки, чтобы все операции опираются на один общий обновляемый ресурсе, чтобы выступать в качестве детектора соударений обновления. Например, если ваша база данных управляет данными, связанными с вашими клиентами, существует, вероятно, общий уникальный ключ, используемый для идентификации любого данного клиента. Эти уникальные ключи часто представляют собой просто цифру или короткую строку (например, Customer-Id). Все строки во всех таблицах вашей клиентской базы данных, вероятно, используют этот же общий уникальный ключ для идентификации конкретного клиента (ведь - вот что такое ключ).

Создать таблицу TRANSACTION, которая содержит два столбца, один столбец для клиента-Id, а другое для некоторых транзакций уникального идентификатора, это обычно лишь временная метка генерируется в начале транзакции (также может быть Задачи- id, это просто должно быть , уникальное для транзакции). Вызовите этот идентификатор транзакции TRANS-KEY. Когда Отображается фаза операции, транзакция имеет идентификатор клиента в первый раз. Затем он обновляет таблицу TRANSACTION для этого идентификатора клиента с помощью своего TRANS-KEY. Оба сохранены в COMMAREA. Обратите внимание, что обновление здесь выполняется только на основе идентификатора Customer-Id, оно заменит текущий TRANS-KEY своим собственным уникальным значением. Вводится фаза , пользователь вводит их изменения и Зафиксирована фаза. На этом этапе транзакция пытается обновить таблицу TRANSACTION на основе сохраненного идентификатора клиента и TRANS-KEY. Если обновление не выполнено, транзакция «знает», то другая транзакция начала работать с одним и тем же клиентом (другая транзакция изменила ТРАНС-КЛЮЧ для того же идентификатора клиента, так что текущая транзакция либо страдает тайм-аутом, либо не указана строка- найденная ошибка). Чтобы сохранить целостность базы данных, текущая транзакция должна отступить. Он отобразит сообщение типа , чтобы пользователь уведомил их о том, что было запрошено параллельное обновление, и что он должен отказаться от запрошенных обновлений . Если, с другой стороны, , TRANS-KEY не изменился для данного идентификатора клиента, будет заблокирован блокировка базы данных, чтобы любая другая транзакция не меняла эту строку для того же идентификатора клиента. Текущая транзакция может затем обновить базу данных, поскольку она не знает, какая другая транзакция просматривала или обновляла данные между временем ее начала работы и временем ее обновления.

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

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

Наконец, транзакция, которая фактически получает обновление базы данных, будет последней для извлечения данных - поэтому мораль этой истории заключается в том, чтобы зайти поздно и закончить рано!

Вышеупомянутое обсуждение не является специфичным для COBOL, оно будет справедливо для всех языков программирования, включая COBOL, используемых для разработки приложений с использованием DB/2 и psuedo-диалога CICS.