Особенности работы локальной сети в режиме файл сервер

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

1. Организация блокировок доступа к общим данным, т.е. как организовать блокировки.

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

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

Лишь немногие из Desktop СУБД обладают встроенными средствами ограничения прав. У Access, Paradox имеются кое-какие встроенные средства доступа. Однако большинство Desktop СУБД таких средств не имеют, и это возлагается на сети.

Блокировки

Как правило, блокировки здесь бывают двух уровней: блокировка таблицы и в ряде случаев блокировка записи. Многие Desktop СУБД работают по правилу блокировки только таблицы (блокировка таблицы значит следующее: кто первый ее сосчитал, тот первый ее и блокировал, остальные не будут иметь доступа до тех пора, пока не освободится).

В некоторых Desktop СУБД (к примеру, FoxPro) можно установить блокировку на уровне записи: одной или набора записей. В FoxPro есть специальная команда, с помощью которой указывается с какой по какую блокируем, а остальные разрешаем.

Типы блокировок:

• Полная блокировка, когда запрещается чтение и изменение и т.д. и т.д.

• Блокировка изменений, т.е. читать данные можно, а изменять нет.

Если при этом используются реляционно-связанные таблицы (т.е. главная и подчиненная таблица), то доступ к каждой из этих таблиц должен делаться порознь. Т.е. мы блокируем одну, блокируем другую и все это делается из приложения. Т.е. снятие и установка блокировки делается с помощью приложения.
Естественно, что когда мы из своего приложения хотим обратиться к какой-то таблице, т.е. установить тот или иной вид блокировки (полную или блокировку изменений), то такого рода запросы могут не всегда проходить, потому что кто-то до нас этим делом захотел воспользоваться. Т.е. зачастую пользователи при блокировках, обращаясь как одним и тем же таблицам, мешают друг другу, поэтому здесь приходится делать специальный доступ, а доступ заключается в организации специальных циклов постоянного «долбления» доступа к нужной таблице, пока короче не освободится (по типу автодозвона).
В СУБД FoxPro такие специальные команды есть, которые в цикле постоянно обращаются и, подключившись, дают соотв. сообщению юзеру. Естественно при отказе нужно обрабатывать соотв. сетевые ошибки.

Для обеспечения лучше доступа в последнее время в последних версиях в частности FoxPro стал использоваться режим буферизации таблиц или даже буферизации отдельных данных, т.е. т.н. метод «портфеля». Это когда данные считываются на компьютер, мы отключаемся и даем формально другим работать в то время, работая с локальными данными в этом портфеле. Здесь возникает обратная задача: когда мы «наигрались» с данными, что-то исправили и хотим вернуть их назад. Если таких игроков оказалось несколько, то возникает вопрос: «чьи данные верные». Здесь получается так, что кто последний тот и прав. Есть еще пессимистические, оптимистические блокировки, блокировки таблиц, блокировки записи, т.е. есть там какие-то варианты, но все равно проблемы напрямую неисправляемы.

В таких системах существуют следующие механизмы обхода:
1. Применяют т.н. симофоры. Под ним понимается следующее: в таблицу водится дополнительная колонка, и как только мы там что-то блокируем, в данной колонке ставится для соотв. записей true (1) или false (0) – занята ли запись или нет.

2. Копирование записи в какие-нибудь переменные, т.е. своего рода буфер для этого есть (предусмотрен). В FoxPro предусмотрено сделать кэширование, в др. СУБД это не предусмотрено, там приходится делать самим.

Обработка сетевых ошибок

При работе группе пользователей неудачный доступ каждого из пользователей приводит к возврату так называемой сетевой ошибки с определенным кодом. Естественно, что должны быть средства, которые обрабатывают эти сетевые ошибки и правильно их интерпретируют. Не то, что там ошибка №546, и пользователь сидит и думает, что произошло, т.е. надо показывать, с чем связана данная ошибка, там разрыв сети, таблица занята и т.п. Для каждой ошибки есть свой номер. В частности в FoxPro есть функция под названием ERROR (стандартная функция), которая интерпретирует текст ошибки.
Что касается перевывода экрана: значит, после того как мы сделали изменения и откатываем от таблицы должен быть запущен режим, который обновляет данные у всех подключенных в данный момент к этой таблице пользователей. Потому как иначе, мы отключились, изменения внесли, а другого на экране все те же данные, и он думает, что там ничего не изменилось, начинает принимать решение при старых данных. Вот этот момент надо исключать автоматически, здесь ничего не происходит. Система немножко старая и дальше ее двигать никто не будет, потому что таков принцип Desktop СУБД.

Комментарии запрещены.