| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > Ахтунг! Где же мои блокировки? |
| Автор: Feliastre 4.2.2005, 09:25 |
| Господа! Поправтье меня, если я не прав. Если мы работаем с удалённой БД через DataAdapter, то: 1. Коннект открывается 2. Данные загружаются 3. Коннект закрывается 4. Данные меняются 5. Коннект открывается 6. Данные загружаются обратно 7. Коннект закрывается А если я открыл приложение и начал работать с загруженными данными. В это время Вася Пупкин открыл то же самое приложение с теми же самыми данными. Потом он изменил данные и записал их в базу(а я ещё работаю). В этот момент у меня данные неактуальны. Легко представить себе ситуацию, когда это упадёт!!! Я прав? И если я прав, то как этого можно избежать? |
| Автор: AntonSaburov 4.2.2005, 10:50 |
| Есть разные виды блокировок - опитмистическая и пессимистическая. Оптимистическая - это как раз то, что ты имеешь. Кто последний сделал изменения - тот и прав Пессимистическая - это ты вытаскиваешь данные и на это время их блокируешь от изменений. Тогда пока ты не снимешь блокировку читать другим еще можно, а вот записать нельзя. Надо смотреть как это может быть реализовано прямо на SQL. |
| Автор: Feliastre 4.2.2005, 11:59 |
| 1. Оптимстическая А если я пытаюсь сделать update удалённой записи? Получается кто первый - тот и прав.... 2. Пессимистическая Здесь у нас на фирме возникли идеи след. толка - семафоры или некая прослойка между клиентом и БД, которая отвечает за подобную байду! Но как то гнило всё это... Есть какие-нибудь идеи как это реалзовать. Пример MS SQL 2000/// Так же интересно для Oracle... |
| Автор: Domestic Cat 4.2.2005, 12:12 | ||||||
Чтобы исправить ситуацию есть 4 способа (при оптимистической блокировке) 1. Вообще забыть про все и обновлять через примари ключ. Тут ни один из юзеров не может быть уверен что именно его изменения сейчас сидят в ДБ 2. Менять указывая не только ключ, но и ВСЕ поля.
Тогда если кто-то до тебя поменял CustomerJob то данный запрос не выполнится и выдаст ошибку 3. Аналогичный способ, только вместо указания всех полей в ДБ добавляется столбец timestamp который сначала у всех рядов одинаков. При изменении ряда сервер его меняет и следующий юзер, если попытается изменить старую запись получит ошибку.
Если ТimeStampColumn уже 0000000002, то этот запрос не пройдет. 4. Менять, указывая в WHERE только те поля, которые ты изменил. Это то же самое, что и способ 2, но чуть экономнее, хотя предполагает дополнительную логику. |
| Автор: Feliastre 4.2.2005, 13:33 |
| Domestic Cat Не понял... Любой из этих апдейтов рухнет если данное поле было удалено... |
| Автор: Domestic Cat 4.2.2005, 18:27 |
| Ну так в том и суть. |