Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Базы данных под .NET > Пессимистичный параллелизм. Ожидание

Автор: Darkmaster 2.6.2009, 20:43

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

Код


Select * From JobTable With (HOLDLOCK) where JobId = 2

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

1) В моей ситуации, когда 1-пользователь редактирует статью с JobId 2, а второй пользователь уже нажимает на кнопку "Сохранить", отредактировав статью с JobId 2 программа немного подвисает. Запись, конечно, не обновляется. В Exception выдается информация о том, что время ожидания прошло. Такой вопрос: стоит ли так поступать или есть какая-то возможность сделать так, чтобы программа сразу же понимала, что такая-то строка заблокирована и ее уже не обновить?

2) Мне кажется, что было бы лучше если в программе была возможность сделать так, чтобы в случае Holdlock строки он не мог даже открыть окно редактирования. Т.е. чтобы каким то-то образом при запросе Select или перед ним строка проверялась на доступность. Возможно ли такое?

Автор: jonie 2.6.2009, 20:56

на мой взгляд в .net так не принято. принято данные кешировать на клиенте и уже потом в базу пихать. Есть даже ADO.NET Sync Framework....

Цитата

Такой вопрос: стоит ли так поступать или есть какая-то возможность сделать так, чтобы программа сразу же понимала, что такая-то строка заблокирована и ее уже не обновить?

наверно перед редактированием вставлять datetime начала редактирования, а при сохранении клиентом1 считывать её и сравнивать с той, что была на момент чтения (в то время второй клиент прочтет дату, сравнит её с getdate()+timeout и если она еще не вышла за таймаут скажет "запись редактируется", иначе перезапишет данные) ...
---
у нас в системе было вообще хитро сделано: обновление шло через процедуру, и sql сервер внутри этой процедуры оповещал клиентов по TCP (свой протокол был) об изменениях... ужасно геморойно.

Автор: SLeN 2.6.2009, 23:27

ИМХО:

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

=>

1. увеличить время ожидания до рационального
2. в этом поможет уровень изоляции транзакции http://msdn.microsoft.com/ru-ru/library/ms173763.aspx

P.S:
Никогда не использовал Pessimistic Concurrency так что реального опыта не имею

Автор: Darkmaster 3.6.2009, 17:46

Спасибо за ответы.

Пошел читать инфу по Sync Framework