A>>Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость

S>Оптимистическая блокировка в общем случае не то чтобы заметно повышает параллельность и масштабируемость. Просто другой подход легко может убить блокировочник

Ну почему же. У меня сейчас на работе — старая система на Informix, которая работает на пессимистических блокировках. И замечательно работает (блокировки, правда, время от рвемени админы ручками удаляют. ну дык это ни на стабильность, ни на скорость не влияет — только на удобство пользования).

S>Концептуально же параллельность повышается только для варианта "один человек редактирует левую половину записи, другой — правую половину записи", что, назовем так, довольно сомнительный подход.

Опять же не согласен
На форме для редактирования какого-нить документа могут быть данные из десятков полей. Так вот один юзер меняет одно поле, другой (в то же самое время) — другое (повезло, замечу в скобках, но тем не менее)

A>>Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).

S>Вывод неправильный (c) полковник Петренко.
S>Данные можно потерять исключительно из-за кривых рук, а не из-за используемой технологии блокировки.

Да. Думать всегда полезно.

A>>Второй вывод. Если используешь оптимистичекую блокировку, то конфликты надо регулировать. Ручками чаще всего.

S>Хм. Я не применял оптимистическую блокировку, поскольку для версионников это просто более сложное в реализации решение без каких-либо преимуществ. В то же время я не вижу серьезной проблемы в аккуратной и универсальной реализации такого подхода.

Хочу напомнить, что мы говорить про блокировщик.

A>>Куда определить транзакции — это, конечно, вопрос. Однако хочу заметить, что ты будешь создавать по транзакции на окно, то это не решит проблему потери данных. А если это не решает проблем, то зачем это делать?

S>Брр. "Вывод неверный".
S>Основное и даже единственное, что решают несколько транзакций — возможность независимого редактирования в немодальном интерфейсе. Например, если началось редактирование документа, потом была вставлена запись в справочник, потом пользователь отказался от сохранения документа — запись справочника сохранится, а не потеряется при rollback-е документа. Тем более это актуально, когда возможно параллельно редактировать несколько документов.

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

A>>Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.

S>Гораздо удобнее их не допускать.

Полностью согласен.

A>>Мне лично кажется логичным, если эти конфликты будет решать нечто в единственном экземпляре — соответственно, и транзакция у этого "нечто" может быть всего одна — так и так он всех в очередь построит.

S>Хм....... Ничего не понял.

Ну, значит, это был гон