Relic Hunterdb2exc,
А что хорошего в блокировочнике? В том, что люди приходят на форум чуть-ли не каждый день спрашивать "как залить в таблицу мильен-другой записей не блокируя таблицу на долго"?

А что хорошего в версионнике? Бесконечные откаты при высокой конкуренции (даже тогда, когда они вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных RDBMS) только один (PostgreSQL)? ;)

Вообще, я за гибридный подход.

Dimitry SibiryakovPgSQLAnonymousБесконечные откаты при высокой конкуренции (даже тогда, когда они
вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных
RDBMS) только один (PostgreSQL)? ;)
Если PG что-то постоянно при конкуренции откатывает, то это его, PG, личные проблемы.

Ничего подобного. Как версионник может не откатывать? Это (традиционно) часть данного подхода к изоляции транзакций.

И вообще, если транзакции конкурируют за какой-то ресурс, можно:
Заблокировать одну из транзакций (подождать) --- подход блокировочника.

Откатить одну из транзакций --- подход версионника.
А какие ещё варианты-то? Или же вы имеете в виду использование блокировок в версионнике (что его частично превращает в блокировочник)?

эттаэттот псевдо пж--ононимус к пг относится так же ,как я к балету

Что, зацепило тебя в прошлый раз, балерина, аж кушать не можешь? ;)

этта-- оно любитель мастдайскуэля.

Не угадал.
эттаи вероятно только , опять таки, как клиентопейсатель.

А ты у нас из PostgreSQL core team, значит? ;)

эттав пг форуме имеет вопросы только относительно сериалайзебл режима (адепт исключительного сериалайзебла всегда и во всём [блокировочный моск, уле])

Да, я адепт консистентности (и SERIALIZABLE, который её гарантирует) и считаю, что смысла от быстрого перемалывания мусора никакого нет. А причём тут блокировки, я не понимаю.

эттаа то, что любая субд будет, будучи в сериалайзебле, то и дело что-то откатывать -- ну это какбе оксиома.
Любая СУБД иногда будет что-то откатывать (DEADLOCK-и, например).

Dimitry SibiryakovДа в общем-то легко.

Отличный ответ, просветляющий. ;)
Не, ну если транзакции выполнять строго по одной, то без отката можно всегда обойтись. ;)

Dimitry SibiryakovИ опять же если кто-то что-то традиционно откатывает, это его личные
половые проблемы. Приведи конкретный пример когда откат транзакции необходим.



Да классический DEADLOCK:


Как тут кого-то не откатить?

Dimitry SibiryakovВо-первых, это не deadlock, а update conflict.

Или так, зависит от реализации. Но откатывать-то нужно !

Dimitry SibiryakovВо-вторых, откатывать таки надо архитектора, который такую дурную логику в БД заложил.

А это уже не дело СУБД. ;) И вообще, это могут быть разные "архитекторы".

Так, пример "когда откат транзакции необходим" я привёл. ;)
И какой же общий способ не откатывать?

Dimitry SibiryakovВыбросить ошибку и пусть с ней приложение разбирается.


То есть в какой-то момент СУБД выбросит ошибку и клиент должен вручную откатить все или часть изменений?

Dimitry SibiryakovНе дело СУБД проявлять неестественный интеллект и инициативу.


Не вижу тут никакого "интеллекта" и "инициативы". Всё по стандарту, не хотите полного отката --- используйте SAVEPOINT, что тут не так-то?

Dimitry SibiryakovКлиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
- ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.

Ну так SAVEPOINT перед каждым запросом и всего делов.

Я вот только не могу понять, как бизнес-логика связана с конфликтами и зачем ей вообще что-то о них знать?

Зачем я в своих транзакциях должен использовать не SERIALIZABLE и предусматривать специальную обработку всех возможных ситуаций (в которой, IMHO, запросто могут ошибиться 99% программистов) вместо общего framework-а (при ошибке откатил-повторил)?

softwarer1. Не очень понимаю, как savepoint спасёт от отката транзакции.

Может откатиться до него.

softwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД "savepoint перед каждым запросом" обеспечивают автоматом.
О каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде, а если не нужна --- не буду использовать. А в Ваших "нормальных СУБД" выбора нет, получается? И это Вы выдаёте за преимущество? ;)

Dimitry Sibiryakovsoftwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД
"savepoint перед каждым запросом" обеспечивают автоматом.
Ну так PG, видимо, не претендует...

С чего это наличие или отсутствие произвольных ограничений вдруг стало определять "нормальность" СУБД?

Alexander RyndinМне одному кажется, что вы какой-то бред несете?
Откуда я знаю, сколько вас здесь, "считающих"? ;)

Alexander Ryndin1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные. Отсюда и deadlocks встречаются редко.
А статистика, подтверждающая "в редких приложениях", у Вас есть? Или это информация агенства ОБС? ;) И как связаны "меняют разные данные" и DEADLOCK-и? Пускай 100500 клиентов конкурируют за одни и те же строки, но если они обрабатывают их в одном порядке, DEADLOCK-ов (без слишком крупных блокировок и т.п.) не будет вообще.

Alexander Ryndin Наличие большого количеств deadlock говорит либо о кривости самого приложения, либо о кривости СУБД (слишком крупные блокировки)

Обычно да.

Alexander Ryndin2) Exception на то и exception, что мы заранее не знаем, какой он может произойти. Может быть deadlock, а может и место на сервере закончиться.

Безусловно, какой будет exception, заранее неизвестно. Но вот deadlock-и и update conflict-ы --- это нормальные ситуации в работе СУБД, и любому Database Developer должно быть известно, как их полагается обрабатывать.

Alexander RyndinНа каждый случай условных веток не напасешься.

Можно и напастись, т.к. обычно ошибки как-то разделяются на группы по severity и т.п.

Alexander RyndinНо всегда есть возможность написать обработчик others, который будет всегда откатывать транзакцию, показывать юзеру текст exception и предлагать повторить всю транзакцию с нуля.

Да Вы что? А если пользователя просто нет ? Кому Вы будете это сообщение показывать?

Alexander Ryndin Какие к черту SAVEPOINT?
Те самые, которые есть в стандарте и во всех "нормальных СУБД"? Вот они все дураки-то, правда? ;)

Dimitry SibiryakovPgSQLAnonymousС чего это наличие или отсутствие произвольных ограничений вдруг
стало определять "нормальность" СУБД?
С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)

softwarerAlexander RyndinМне одному кажется, что вы какой-то бред несете?
Да не то чтобы бред. Слова уважаемого коллеги напоминают мне поведение юного головастого студента с большим самомнением, который нахватался вершков теории и при нуле практики начал придумывать улучшения и прочие единственно правильные подходы.
А мне Ваши, может, тоже чего-то напоминают. А аргументы-то есть у Вас?

softwarerPgSQLAnonymousпропущено...
Может откатиться до него
На предыдущем допросе (тм) Вы показали, что версионник должен отказывать транзакцию. Как откатиться до savepoint-а после отката транзакции и зачем?
Естественно, никак. Он может откатиться до savepoint-а вместо отката транзакции, если это нужно.

softwarerPgSQLAnonymousО каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде,
Вот именно о таких обезьянках.
Нда. То есть возможность наличие выбора и возможность тривиально реализовать implict savepoint --- это недостаток, а отсутвие выбора --- это преимущество? Интересная у Вас логика.

softwarerЗа преимущество я выдаю удобную и правильную работу. А мучающиеся с грязным чтением, мумпсом и прочим каменным веком имеют полное право гордиться тем, что у них зато есть выбор.
Как здесь появились "грязное чтение, мумпсом и прочий каменным век"?
Ни с чем таким в PostgreSQL и MS SQL, например, где вышеописанный выбор есть, можно не мучаться (а с грязным чтением в PostgreSQL и не получится)...

Dimitry SibiryakovPgSQLAnonymousмне это поведение почему-то совсем не кажется "нормальным"
Выше я уже писал про неестественный интеллект и инициативу. Ты явно и недвусмысленно
приказал серверу закоммитить транзакцию не смотря ни на что. Он её закоммитил. Почему
точное выполнение сервером твоих приказов ты считаешь ненормальным?

Я говорю, что мне это поведение кажется ненормальным, потому что я привык к другому. ;) Если его учитывать, то ничего плохого тут нет, я приказал --- он закоммитил, формально косяк здесь только мой. Но без implicit savepoints я могу выполнить это всё одним запросом/пакетом и знать, что данные не потеряются, а здесь нет, и это мне кажется ненормальным. ;(

pkarklinPgSQLAnonymousпропущено...

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)

Я дико извиняюсь, что встреваю, но, в нормальной СУБД:




А в другой нормальной СУБД:


И что? ;)