Многопользовательское приложение

Привет товарищи программисты! Есть вопрос касательно проектирования приложения WinForms. Планирую создать приложение, многопользовательское приложение, что-то на подобии журнала заявок. Заявка может создаваться, вешаться на конкретных людей, редактироваться, менять свое состояние и т.п.

Вопрос следующий: Каким способом организовать работу приложения с базой данных? Суть вопроса состоит в том, как предотвратить одновременные запросы. То есть, 2 пользователя одновременно открывают заявку, редактируют ее и затем решают сохранить изменения. Разумеется сохранены будут те данные, которые записал пользователь, нажавший на кнопку "Сохранить" позже. Мне следует избежать этой проблемы.

Заранее спасибо!

0

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

0

Сообщение от Besnywka а что в этом запросе на апдейт такого примечательного?

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

Сообщение от Besnywka Каким образом он влияет на доступность записи для других пользователей?

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

Сообщение от Besnywka Разве не сама СУБД ставит блокировку на запись, которая в данный момент изменяется?

СУБД ставит блокировку на обновление данных в момент выполнения запроса, а не в процессе работы. Как я понял ТС это не устраивает, в данном случае никакие дополнительные блокировки не нужны.

2

в принципе косвенно "отловить" работу чужой транзакции возможно. К примеру поставить для вашей транзакции режим блокировки nowait, тогда sql вернет Вам сообщение с ошибкой о возникшем конфликте с более ранней транзакцией.

0

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

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

По предложению "первый записал остальным ошибка" - это опять таки не юабилитично - гораздо лучше пользователю в момент открытия бланка редактирования сделать его readonly, и сказать, что такой-то уже редактирует эту запись, чем торжественно обломать пользователя после того, как он, потратив время и силы, заполнит много полей данных и радостно нажмёт кнопку "сохранить". Да и много WHERE предполагает индексы по всем контролируемым полям (тормоза при вставке), либо тормоза при обновлении, что тоже не всегда приемлемо.

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

1

ksk, согласна с Вами насчет юзабилити. Но все–таки насчет транзакций хочу добавить, что транзакция будет выполняться единожды при каждом сохраннии данных. При плвторном редактировании производится уже следующая (новая) транзакция, так что из–зяа одного пользователя вся работа не встанет. А транзакцию без ожидания при ее прерывании можно перезапустить. И ообще, насколько я знаю, по умолчанию любая операция с данными рассматртвается СУБД в качестве транзакции с ожиданием

0

ksk, как не крути но самый оптимальный вариант это твой. И прозрачен и универсален и легко расширяем.

Но всем остальным тоже спасибо, есть над чем поразмыслить!

0

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

Клиент должен держать открытую транзакцию из окна редактирования?
В принципе это должен быть работоспособный вариант (правда, я не пробовал так делать).
И я не знаю, что будет, если в этот момент отключат питание клиенту / порвётся сеть итд.
Сервер просто удалит из transaction_log незакоммиченную транзакцию и разблокирует запись?

Kilimangaro, рад, если оно было полезным. Другие методы тоже существуют, но я сторонник "ручной работы" именно в силу гибкости такого подхода.

0