Архитектура импорта файлов: батчем + интеррактивно

[Владимир Максимов]

Цитата:

Сообщение от Lankey

Поясните, пожалуйста, зачем (3), если сделать (2), то есть, уже по таблице,вроде, можно понять, заблокирован файл или нет.

Запись в лог - это история. Что БЫЛО сделано. Инструментом контроля, в общем случае, служить не может

1. Первый пользователь выбрал файл
2. Второй пользователь выбрал файл
3. Первый пользователь сделал запись в лог
4. Что помешает второму пользователю также сделать запись в лог?

Т.е. просто будут 2 записи в логе и 2 пользователя "одновременно" попытаются обработать файл

В случае же блокировки ресурса, первое, что делает пользователь после выбора - пытается заблокировать ресурс. Удалось? Можешь продолжать. Нет? Этот файл взял другой пользователь

[Lankey]

Цитата:

Сообщение от Владимир Максимов

4. Что помешает второму пользователю также сделать запись в лог?

"Мешает" проверка на то, что файл с таким именем уже есть в логе, и его статус != Обработан

То есть, такой лог , в моем понимании, альтернативен Вашему предложению использовать sp_getapplock . Только лог дополнительно полезен тем, что потом можно его анализировать потом, а sp_getapplock - нет

[Владимир Максимов]

Цитата:

Сообщение от Lankey

"Мешает" проверка на то, что файл с таким именем уже есть в логе, и его статус != Обработан

Я так понимаю, что Вы предполагаете перед записью в лог выполнять поиск.

1. Первый пользователь ищет запись. Не нашел
2. Второй пользователь ищет запись. Не нашел
3. Первый пользователь создает запись
4. Второй пользователь создает запись

Уникальный индекс по имени файла? А если в разное время приходили файлы с одинаковым именем? По каким критериям выполнять поиск?

Вы не контролируете то, что получаете из-вне системы. Статусы могут контролировать только записи таблицы. Но что именно записано в эти таблицы?

При работе с данными, которые приходят из вне системы, использование таблицы блокировок для контроля - крайне не надежный инструмент.