funikovyuri Timm

Я говорю про http://www.orafaq.com/papers/locking.pdf
про что говорите вы я не знаю, могли бы последовать своему совету и привести пример.
тынц
3 глава.
Второй метод, который называют оптимистическим блокированием, состоит в том,
чтобы сохранять старое и новое значения в приложении и использовать их при измене-
нии следующим образом:
Update table
Set column1 = :new_column1, column2 = :new_column2, ....
Where column1 = :old_column1
And column2 = :old_column2
Здесь мы оптимистически надеемся, что данные не изменились. Если в результате
изменена одна строка, значит, нам повезло: данные не изменились с момента считыва-
ния. Если изменено ноль строк, мы проиграли — кто-то уже изменил данные и необхо-
димо решить, что делать, чтобы это изменение не потерять. Должны ли мы заставлять
пользователя повторно выполнять транзакцию после запроса новых значений для стро-
ки (сбивая его с толку, поскольку снова может получиться так, что изменяемая им строка
обновлена другим сеансом)? Стоит ли попытаться совместить изменения, разрешая кон-
фликты двух изменений на основе бизнес-правил (что требует написания большого объе-
ма кода)? Конечно, для отключившихся пользователей последний вариант — единственно
возможный.

Стоит заметить, что и в этом случае тоже можно использовать оператор SELECT FOR
UPDATE NOWAIT. Представленный выше оператор UPDATE позволяет избежать по-
тери изменений, но может приводить к блокированию, "зависая" в ожидании заверше-
ния изменения строки другим сеансом. Если все приложения используют оптимисти-
ческое блокирование, то применение простых операторов UPDATE вполне допустимо,
поскольку строки блокируются на очень короткое время выполнения и фиксации изме-
нений. Однако если некоторые приложения используют пессимистическое блокирова-
ние, удерживая блокировки строк достаточно долго, имеет смысл выполнять оператор
SELECT FOR UPDATE NOWAIT непосредственно перед оператором UPDATE, чтобы
избежать блокирования другим сеансом.
Итак, какой же метод лучше? По моему опыту, пессимистическое блокирование очень
хорошо работает в Oracle (но вряд ли так же хорошо подходит для других СУБД) и име-
ет много преимуществ по сравнению с оптимистическим.

а вот добавлять TCN в каждую таблицу - это сильно...

funikovyuri Timm
Вы, я надеюсь, поняли что пессимистической блокировкой называли не то что надо?
я об этом раньше уже сказал.
funikovyuriЭтой фразы не понял!?
ну как же. прочитал статью по ссылке. оттуда:

Worked Example.
...
и так далее...

funikovyuriА... ну нормальные люди для этого timestamp используют :)
и как? успешно? а сколько у вас таблиц с таймстемпами?
имхо это отвратительно.

OU2 Timm:
я думаю вы не правы в данном вопросе. Пессимистический контроль транзакций всегда будет дороже по следующим причинам. Поскольку пессимистический контроль предполагает полную сериализацию это значит что как минимум:
1. В период всего выполнения текущей транзакции все остальные транзакции блокируются и кешируются dbms. После завершения текущей транзакции рдбмс должен взять из кэша следующию транзакцию и так далее. То есть dbms выполняет определенное количество дополнительной работы (блокировка и каширование) вызванной сериализацией транзакций.
2. Перед началом новой транзакции dbms должен будет кэшировать сегмент памяти и/или сделать записи в transaction log которые необходимы для атомарности операций.

Оптимистический контроль не требует вышеуказанных действий со стороны dbms:
1. В период всего выполнения текущей транзакции все остальные транзакции не блокируются и не кэшируются если между ними не возникает конфликта. Только если между транзакциями существует конфликт dbms должен будет выполнять какую то дополнительную работу.
2. Перед началом новой транзакции dbms не должен (во всяком случае не всегда) будет кэшировать сегмент памяти и/или сделать записи в transaction log потому что атомарность операции либо не требуется, либо ей ничего не угрожает.
It depends on DBMS :)
В Оракле сериализуется только запись только блокированных строк. Накладные расходы на выполнение select for update nowait сравнимы с обычным select. Это является простой проверкой на занятость ресурса (непосредственно перед его обновлением). Если ее не будет, то все транзакции на запись будут сериализоваться. В любом случае.
Вопрос: что имеется ввиду под "кэшированием транзакций"? не ясно :-\

я использовал неправильный термин, с этим согласен. (хотя мне кажется использование явного блокирования строк(и) плохо соотносится с термином "оптимистичное блокирование")
funikovyuriЯ делал проект для Oracle 9i, J2SE5 и Hibernate. Таблиц именно этого модуля было где-то 10-15 штук - все с timestamp'ами. Модуль являлся частью системы из порядка 600-800 таблица в которых timestamp не применялись. Важно отметить что всю работу по использованию timestamp колонок брал hibernate. Очень кстати доволен остался :)
кто? хибернейт? правильно, ему все по барабану
можете привести здесь выдержки что и как? пример думаю будет полезен.

OU2 Timm:
авторВ Оракле сериализуется только запись только блокированных строк.ммммм, допустим мы говорим о блокировки записи а не целой таблицы, принцип решения проблемы все равно останется таким же как и при блокировки всей таблицы.
Если бы видеть детальное описание принципов работы oracle dbms дискуссию можно было бы считать закрытой, но до тех пор я всетаки останусь на своих позициях (не то что бы я вашим доводам не верил конечно, просто это "классика жанра"). авторВопрос: что имеется ввиду под "кэшированием транзакций"? имеется ввиду помещения блокированых транзакций в очередь до их выполнения.
К счастью нет.
Да. Теперь я уверен что мы говорим о разных подходах в DBMS. Очень хорошо этот момент описан у Кайта (ссылка выше, 1 глава - must read)
Ниже приведены принципы блокирования в СУБД Oracle.
• Oracle блокирует данные на уровне строк и только при изменении. Эскалация бло-
кировок до уровня блока или таблицы никогда не выполняется.
• Oracle никогда не блокирует данные с целью считывания. При обычном чтении
блокировки на строки не устанавливаются.
• Сеанс, записывающий данные, не блокирует сеансы, читающие данные. Повто-
рю: операции чтения не блокируются операциями записи. Это принципиально от-
личается от практически всех остальных СУБД, в которых операции чтения бло-
кируются операциями записи.
• Сеанс записи данных блокируется, только если другой сеанс записи уже забло-
кировал строку, которую предполагается изменять. Сеанс считывания данных ни-
когда не блокирует сеанс записи.