а где проблема то? исключение? так можно (нужно) сообщить юзеру об этом...

Крошкин ДимонПроблема как раз в исключении.
Исключение может быть возбуждено нарушением констрайнта, недоступностью таблицы, неккоректными параметрами.
При таком подходе надо анализировать код ошибки sqlException-а, а хочется универсальный метод и без гемороя. :-)
как в предыдущем мессадже if exists.......(там мы возможно получим что у нас обновилось 0 записей и можем делать на основании этого выводы, что не все гладко.
на основании вашего примера вы не можете делать вывод. (надо объяснять почему?)
на основании исключения вы можете делать вывод.
разницу чувствуете?

Вы говорите о перпендикулярных вещах...

ваш пример:
1) проверяете наличие записи
2) делаете апдейт.
между 1 и 2 в общем случае может пройти сколько угодно времени, поэтому ваш вариант не обеспечивает требования "не получать исключение".
Правильное решение должно делать п.1 во втором пункте. Если юзера не информировать, сколько чего было обновлено, то это решение вида "нам по.уй на юзера". Если информировать - то жить можно.
Но мне такой подход не нравится.

funikovyuri Sherst
Знаю точно, что поддерживается сервером Oracle, на счет остальных серверов
не уверен.
Это все нормальные сервера поддерживают только вот назначение у этой штуки другое - а именно показывать серверу что данное множество записей которое мы сейчас читаем будет изменено далее в ЭТОЙ ЖЕ транзакции. Реализация же с помощью for update пессимистической блокировки - обычно слишком дорогое решение.

авторКрошкин Димон

Сделайте общий обработчик для SQLException'ов отображащий сообщение об ошибке в понятном пользователю формате.
? пример в студию.

funikovyuri Timm
? пример в студию.

Чего пример? Может еще сплясать?
если хотите.
пример когда select for update является дорогим решением. вы же говорите обычно это так, значит с примерами это подтверждающими проблем быть не должно.

funikovyuri Timm funikovyuri Timm
? пример в студию.

Чего пример? Может еще сплясать?
если хотите.
пример когда select for update является дорогим решением. вы же говорите обычно это так, значит с примерами это подтверждающими проблем быть не должно.
Моя мысль сводится к тому что внесение взаимодействия с пользователем внуть транзакции дороже (в смысле как времени выполнения так и ресурсов), чем оптимистическая блокировка. Вы с этим не согласны?
не понял что имеется ввиду в начале фразы. говорите попроще.
я так понял: пессимистичное блокирование дороже чем оптимистичное. оно?
вот это я хотел прояснить: что значит "дороже", в чем выражается и почему.

funikovyuri Timm
не понял что имеется ввиду в начале фразы. говорите попроще.

Слушайте, Timm, я вам чем-то обязан, или у вас вообще ко всем притензии такие?

Timm
я так понял: пессимистичное блокирование дороже чем оптимистичное. оно?
вот это я хотел прояснить: что значит "дороже", в чем выражается и почему.


Я написал в чем и что значит "дороже", вроде по-русски. Именно дороже, а не удобнее. Почему, ну хотябы потому что на поддержание такой блокировки тратяться ресурсы как сервера (что может быть очень плохо) так и клиента (что менее важно). Обычно с этим не спорят. У pessimistic locking есть много фанатов, особенно из тех специалистов кто привык писать внутренние клиент-серверные приложения. Я с этим и не спорю, говорю лишь что она дороже. Из-за этого, например, для web-приложений с большим числом пользователей pessimistic locking неприемлема в принципе.
1. никто ничего никому не обязан. идет обычная дискуссия, которую я хочу повернуть в русло конкретики.
2. я пытаюсь выяснить простые вещи: почему вы считаете что пессимистичное блокирование дороже? в чем это выражается? какие ресурсы тратятся? хочу узнать конкретику, не слушая общие слова (их везде полно).
3. ваши доводы сводятся к "обычно с этим не спорят". я не спорю. хочу узнать почему (сорри за повторение, но может хотя бы так станет понятно че я ваще тут делаю) и увидеть примеры.
PS. может мы вообще про разные вещи говорим? здесь я под "пессимистичным блокированием" имею ввиду обычное оптимистичное с предварительной проверкой (select for update nowait) непосредственно перед обновлением данных.

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 никогда не блокирует данные с целью считывания. При обычном чтении
блокировки на строки не устанавливаются.
• Сеанс, записывающий данные, не блокирует сеансы, читающие данные. Повто-
рю: операции чтения не блокируются операциями записи. Это принципиально от-
личается от практически всех остальных СУБД, в которых операции чтения бло-
кируются операциями записи.
• Сеанс записи данных блокируется, только если другой сеанс записи уже забло-
кировал строку, которую предполагается изменять. Сеанс считывания данных ни-
когда не блокирует сеанс записи.