Здравствуйте, Arsu, Вы писали:

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

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

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

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

Вывод неправильный (c) полковник Петренко.

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

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

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

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

Брр. "Вывод неверный".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Arsu, Вы писали:

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

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

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

Да ладно вам, тормоз — тоже человек

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

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

Здравствуйте, Arsu, Вы писали:

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

Не совсем понял, на что именно Вы возражаете Преимуществ оптимистической блокировки это не показывает. С тем, что аккуратно используя пессимистическую блокировку, можно и не убить блокировочник, я нисколько не спорю.

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

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

С чем Вы не согласны, я опять же не понял, с учетом того, что сказали Вы то же самое, что и я.

Наконец, обращу Ваше внимание на слово "заметно". Прикиньте вероятность такого совпадения — и, собственно,...

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

Хм. Хочу напомнить, что вопрос был задан про Interbase; что касается моего ответа, то он не зависит от сервера. Я только упомянул, что лично не проверял свое предположение, поскольку не было нужны делать оптимистическую блокировку.

Здравствуйте, Ptaha, Вы писали:

P>угу, особенно если к таблице Person- есть подчиненная — PhonesOfPeron

C точки зрения редактирования подчиненных данных в отдельной транзакции есть один технический вопрос — нужно будет ввести понятие "подчиненной транзакции", для того, чтобы нельзя было закоммитить деталь при вставляемом но незакоммиченном мастере. Впрочем, я не вижу в таком подходе особого смысла; есть понятие "бизнес-объекта", и как бы они ни были выделены, логично редактировать объект целиком (в одной транзакции), а не по частям. В то же время вполне возможно одновременное редактирование либо независимых бизнес-объектов (тех же нескольких документов), либо зависимых (тех же записей в справочниках).