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

Крошкин ДимонПроблема как раз в исключении.
Исключение может быть возбуждено нарушением констрайнта, недоступностью таблицы, неккоректными параметрами.
При таком подходе надо анализировать код ошибки 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) непосредственно перед обновлением данных.