4.3.1. Разработка многопользовательского приложения

 

Visual FoxPro хорошо работает в многопользовательских средах. Рассмотрим ситуации, в которых возникают конфликты, и те инструменты Visual FoxPro, которые помогают их предотвратить или разрешить. Сначала разберем механизмы блокировки, которые предоставляет Visual FoxPro. После этого перейдем к изучению стратегии для отдельных таблиц (буферизация строк и таблиц).

Если ваше приложение обслуживает локальную сеть, Intranet или Web-сервер, нельзя исключать возможность того, что сразу несколько пользователей захотят редактировать одни и те же данные. Конечно, если вам повезет, этого не произойдет. Однако вероятность подобных столкновений увеличивается по мере того, как растет число пользователей системы. Чем их больше, тем чаще возникают конфликты. Если вы не хотите полагаться на случай, то вставьте в свое приложение коды, благодаря которым оно сможет должным образом урегулировать возникающие проблемы.

Управление межпользовательскими конфликтами в Visual FoxPro состоит в следующем: задаются различные команды установок и блокировок, которые будут служить «арбитражем» для конкурирующих запросов. Блокировка снабжает пользователя «замком», который не дает другим пользователям изменять его данные. Хотелось бы, чтобы это происходило автоматически, без применения кода. До определенной степени это действительно возможно. Visual FoxPro предоставляет несколько режимов блокировки, которые требуют минимум кодов. Также VIisual FoxPro автоматически управляет запросами и по умолчанию посылает пользователю сообщения при конфликтах. Однако не существует стратегии, которая годилась бы для всех возможных ситуаций, поэтому лучше изучить все доступные команды Visual FoxPro.

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

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

·       Конфликты при редактировании. Случается, что два или более пользователя одновременно пытаются редактировать одни и те же данные. Возможно ли сделать это в вашем приложении? Или оно «разрешит» редактирование одному из пользователей, а остальные будут ждать своей очереди?

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

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

При разработке стратегии разрешения конфликтов между пользователями надо учитывать:

·       тип используемых данных;

·       требования к эффективности работы приложения;

·       особые требования пользователя;

·       вероятность конфликтов;

·       требования к организации сопровождения  приложения.

 

Тип используемых данных. Иногда типы данных настолько отличаются, что вам не удастся выработать единую стратегию. Кроме того, они могут оказаться разными для разных приложений. Нередко базы данных требуют очень аккуратного обращения. В этом случае нельзя допускать, чтобы пользователь вносил в них какие-либо измене­ния и писал поверх того, что написано другим. Если вы это разрешите, данные станут противоречивыми, а пользователь запутается. Однако данные не всегда так уязвимы, и если один пользователь станет писать поверх изменений, сделанных другим, это не обязательно вызовет серьезные последствия.

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

Особые требования пользователя. У каждого пользователя свои особенности характера. Возможно, он потребует, чтобы в любой момент времени доступ к определенному фрагменту информации имел только один человек или процесс. Например, у одного из ваших клиентов может быть деловое правило, гласящее, что с лицевым счетом Account в каждый момент времени работает только один инспектор. Тогда ваше приложение должно отвечать этому условию. Другой клиент может предъявить прямо противоположное требование. Поэтому всегда старайтесь выяснить, есть ли у пользователя специальные пожелания.

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

Требования к организации сопровождения приложения. При обсуждении блокировки часто забывают, что каждое рабочее приложение должно обладать некоторыми средствами сопровождения. В их функции входят диагностика, обновление и переиндексация. Часто такие действия требуют эксклюзивного доступа к системе. Например, это необходимо при переиндексации и упаковке таблицы. Аналогично, при диагностике и глобальных изменениях в базе данных может понадобиться эксклюзивный доступ к базе в целом. Во всех этих случаях для других пользователей доступ должен быть запрещен. Многие приложения осуществляют сопровождение, запуская специальные программы в ненапряженный период (например, около полуночи). При этом используется программа запуска сопровождения.

Итак, когда один из пользователей редактирует некоторые данные, другие пользователи не должны иметь к ним доступа. Если вы приняли такое решение, можете использовать блокировку - инструмент, который есть во всех базах данных. Взаимодействуя с вашей операционной системой и/или локальной вычислительной сетью, Visual FoxPro устанавливает и снимает блокировки на основании запросов, которые поступают от запущенных экземпляров ваших приложений.

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