Привет всем!

Ребят, кто как решал проблему многопользовательского доступа и на какие грабли при этом наступали. Сам думаю использовать запрос select for update.

Т.е. на Java будет выглядеть примерно так:



В качестве сервера баз данных использую Oracle. 

Не могу понять, в чем проблема-то? 

Если 2 человека попытаются одновременно отредактировать одну запись в таблице, то результат будет
плачевным ... 

Способы объехать такую несправедливость, как одновременные запросы на update:

• select for update (только для Oracle);
• транзакции (отключить autocommit), тогда в БД попадут данные последнего updater'а;
• работа ВСЕХ клиентов с transaction isolation == serialized

 

Стоп-стоп-стоп, товарищи. Тут далеко не все так просто.

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

Если выборка и обновление происходят в рамках одной транзакции, то тут все достаточно просто. Можно, как уже упоминалось, воспользоваться конструкцией select for update (хотя это и некошерно в силу непереносимости). Гораздо удобнее ввести внешнюю синхронизацию: через примитивы синхронизации Java или через атрибуты управления транзакциями (если речь идет о компонентной архитектуре). Тут все основывается на предположении, что транзакции короткие и быстрые.

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

Между тем конфликты - вещь абсолютно реальная.  Расмотрим такую, очень даже возможную, ситуацию:

• Юзер А открывает форму для редактирования какой-то инфы (например, описание товара). Данные для формы выбираются из базы.
• Юзер Б открывает форму для этого же товара.
• Юзер А меняет название, сохраняет форму
• Юзер Б меняет артикул, сохраняет форму

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

Как с этим бороться? Ну, есть разные способы, но вот легких среди них - увы, нет. Перечислю несколько наиболее распространенных.

Избирательное обновление

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

Недостаток в том, что вместо одного общего апдейта придется писать команды для обновления каждого поля.

"Версирование" записей

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

Недостаток: усложнение сценариев диалога.

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

А если хочешь более конкретного совета - выкладывай исходные данные.  

Это сообщение отредактировал(а) Stampede - 27.7.2006, 23:03

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

Это как это? Использовать конструкции Hibernate не используя сам Hibernate? Объясни.

"Версирование" записей в Hibernate реализовано. Если проект позволяет, можно использовать. Сделать оптимально избирательное обновление мне кажется уж слишком сложно. 

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

А какая разница. Все равно UPDATE на одни и те же записи возможен, а в случае кумулятивного, шанс коллизий только возрастает.

А по поводу UPDATE, в компонентах dbExpress от Борланда реализованна следующая стратегия: производится UPDATE в условии WHERE которого указаны, все старые значения полей, и если хоть одно поле изменилось, то UPDATE затронет 0 полей, и пользователю будет выдана ошибка, что запись изменилась пока он "ковырялся в носу".

У нас же в системе все реализованно еще хитрей, есть 3 режима работы (у нас правда не СУБД, а своя система):
1. Все поля обновляются в реальном времени и если пользователь правит поле, а оно меняется, то его изменения будут потеряны.
2. Поля не обновляются, но в случае конфликта пользователь получит сообщение об ошибке.
3. Поля не обновляются, и все изменения прописываются поверху, невзирая на конфликты.