Hi All!

Попробуй сразу всем ответить...

2 burgos

> Как вы сами отнеслись бы к следующей ситуации: вы редактируете текст
> (например один из модулей вашей программы) и при попытке его сохранения
> система выдаёт вам сообщение, что вы ранее этот самый модуль был изменён
> другим пользователем и изменения, внесённые вами, будут проигнорированы
> (естественно по системным соображениям)

Ты возможно удивишься, но для C# проекта мы используем Subversion - систему
управления конкурирующими версиями. И я действительно могу править тот-же
модуль, который правят в это время другие разработчики - и мне это УДОБНО -
а вот вариант предлагаемый системой Source Safe - мне НЕ УДОБЕН - поскольку
там только ОДИН человек может в один момент времени править один модуль - и
пока он его не "освободит" - все остальные ждут :( При этом никак не
принимается во внимание, что в модуле может быть 50 методов, и при этом
разные люди будут править разные часть модуля.
При сохранении (реально это не сохранение файла, а Commit - т.е. перенос
моего "рабочего" файла в общий репозиторий - ну это довольно близкая
аналогия с фоксовым буфером и его "сбросом" в базовые таблицы) действительно
идёт сообщение о "конфликте" - и тут-же я имею возможность этот конфликт
разрешить - при этом я совсем не обязан "терять" свои изменения! я могу либо
полностью переписать имеющиеся данные своими (что конечно жестоко по
отношению к другим), либо провести объединение - более того система сама
предложит наиболее корректный вариант "слияния" моих изменений с чужими!
Так что тут ты сильно заблуждаешься, если считаешь что без блокировки никак
не обойтись.
Насчёт защиты от дурака полностью согласен! но как же ты победишь самую
"дурацкую" ситуацию - когда пользователь начал чего-то править, а потом
бросил всё и пошёл скажем обедать? Вот если бы без блокировки - то и
проблемы нету.

2 Alex_Ustinov

Твоя ситуация не просто "надуманная" - она НЕВОЗМОЖНАЯ - т.к. при "откате"
вторым пользователем в базе ничего не изменится - и то что ввёл первый
пользователь сохранится. И даже при попытке "сохранения" вторым
пользователем своего буфера не произойдёт ничего катастрофического - система
обнаружит конфликт совместного изменения и покажет (если конечно не ленится
и реализовать это - благо все средства имеются) - текущее значение полей, их
новое (или "предлагаемое") значение, и даже старое значение (то которое было
видно ДАННОМУ пользователю на момент начала редактирования) - и пользователь
сможет сделать осознанный выбор - опять же вовсе не нужно принудительно
"отменять" его изменения - может он исправил ещё лучше чем это сделал
первый - не только одну буковку в ФИО, но и адрес, возраст, пол и т.п. :)
Насчёт "инструкции" - ты видел хоть одного пользователя который прочёл
инструкцию? Или ты считаешь что перед большим начальником пройдёт отмазка
типа "в инструкции это было описано"?

> И никто не предлагал бокировать чтение.

Ага - тогда тебе надо срочно читать про consistent reads - ибо для ЧТЕНИЯ
тоже иногда нужны блокировки. Конечно в Oracle с этим получше - т.к. он
версионник и вместо блокировки способен просто разным клиентам отдавать
разные (но главное - согласованные!) данные из одной и той-же таблицы, или
того сложнее - из разных таблиц :) Или ты считаешь нормальным, если во время
формирования отчёта пройдёт некоторое изменение и половина отчёта покажет
данные ДО изменения а вторая половина - после :)

2 Недоходящий

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

Posted via ActualForum NNTP Server 1.3