Гаджимурадов РустамWildSeryIvan_Pisarevsky > А на заказах так вообще обратный отсчет сделан, не уложился в минуту и привет.
А здесь мы селёдку заворачивали
Кажись, обсуждение ушло в сторону от исходного вопроса
(я вовсе не против, в данном случае) и я всю ветку не читал,
но AFAIK по вопросу "как, когда и насколько лочить" есть
всего 2 крайних варианта:

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

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

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

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

Варианты типа "не уложился в минуту" можно/нужно считать
экзотическими и маргинальными, хотя тоже имеющими право
на жизнь, конечно (в каких-то ситуациях - возможно, даже и
оптимальными, с т.з. простоты кодинга, например ).


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