FlyGuyЕсли с обычными новостными/контент-ориентированными сайтиками всё понятно, то с интерпрайз средой не совсем.
Мне, например, всегда хватало дефолтной изоляции базы данных.
Но сейчас есть один проектик, где планируется работать с деньгами, обеспечить одновременную работу нескольких пользователей.
Что посоветуете почитать ?
Посоветую почитать http://www.postgresql.org/docs/devel/static/transaction-iso.html и использовать SERIALIZABLE, как там описано.

йоксельознакомиться -- правильный совет
использовать -- в корне неверный

Правильный совет: не используй RDBMS вообще, раз они тебе на самом деле не нужны.

йоксельPS
кг/ам
Сам ты это слово. По теме есть что сказать?

форупдатеPgSQLAnonymousиспользовать SERIALIZABLEкакие преимущества даст serializable по сравнению с явной блокировкой, кроме возможности потренироваться в написании обработки конфликта сериализации?

Он даёт гарантию корректности в любой ситуации, в отличие от явной блокировки. А если в приложении нет обработки стандартных ситуаций в работе с СУБД (DEADLOCK-ов, конфликтов сериализации), оно уже кривое.

йоксельчукча не только кг/ам, но ещё и явно нечетатель

О, чейтатель выискался. ;) То есть по упомянутой теме тебе сказать нечего?

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

Да-да, "уже давно сказано, что Земля плоская". Кем эта чушь сказана? Ты вообще понимаешь, что используя "явное руление" блокировками, ты получаешь тот же самый блокировочник, только кривой и вручную?

Кстати, чистый "гнусный блокировочник" в ситуациях высокой конкуренции за ресурс зачастую выигрывает у чистого версионника по производительности, как же так? ;)

йоксельPgSQLAnonymous,
ты, ять, не тычь, я те не иван кузьмич

Уважения ты у меня не вызываешь.

йоксельесли есть задача лочить ресурс, то лочить его надо -- чюдес не бывает

Да ты что? Про другие методы обеспечения сериализации/изоляции, ты, небось, и не слышал?
Вот прямо-таки практический пример: http://en.wikipedia.org/wiki/Mimer_SQL

йоксельно лочить явно -- более зрячее решение, чем тыкаться в потемках, отдав СУБД контроль.

Да, более "зрячее". Так же, как писать на ассемблере --- более "зрячее" решение, чем отдать компилятору (или, хуже того, интерпретатору) контроль. ;) Я уже говорил --- если тебе RDBMS не нужны, не используй.

йоксельТам, где у тя, ять, 2-й (и более) ползатель запустит чо-нть, надавит кучу кнопок, и получит через полчаса облом из за сериалайзебла -- в случае явного руления ресурсами он получит из приложения сообщение, что ресурс занят уже в момент попытки взять его на обработку.


Во-первых, у тебя что, в транзакции "ползатель запустит чо-нть, надавит кучу кнопок"? Такое приложение, опять-таки, кривое по определению. Во-вторых, в любой БД модифицирующие транзакции должны быть короткими, откуда ты взял полчаса-то? И, в таком случае, от того, что "он получит из приложения сообщение" быстрее-то ничего не обработается, полчаса ему подождать придётся (а то и более). И, в-третьих, какое отношение это имеет к PostgreSQL? У него-то как раз версионный SERIALIZABLE.

йокселькак в случае предварительного FOR UPDATE NOWAIT
так и в случае логической блокировки.
при этом мульон отчётов, которые должны вариться в read commited, и никому не мешают -- и будут в нём вариться
компрене ? или дерево не всасывает?

Какого хрена отчёты должны вариться в read commited? Ещё одно "общеизвестное" правило? Т.е. всем должно быть пофиг, имеет ли отношение к реальности то, что они там возвращают?

Проблема всех уровней изоляции, кроме SERIALIZABLE, в том, что куча программистов думает, что умеет ими пользоваться, но это только их мечты. Ну как, дерево всасывает? ;)

йоксельPgSQLAnonymous,
когда мне вдруг и если оказывается нужен хотя б рипитбл рид -- я его явно задаю на транзакцию. последний раз когда я это делал -- в конце концов выяснилось -- что перезаложился. [вернее удалось сменить немного алгоритм, и логику] Обошелся обычным read commited по итогу.
это к слову про умейства.


Отличная иллюстрация того, что я говорил: "Проблема всех уровней изоляции, кроме SERIALIZABLE, в том, что куча программистов думает, что умеет ими пользоваться, но это только их мечты".

Вопрос-то простой: с чего ты взял, что ты сделал это правильно ?

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

Нет, абсолютно. Меня печалит, если "только-что сваренный отчот" не соответствует никакому состоянию базы.

йоксельа должно, при таком-то подходе к "актуальности".

Нет, не должно (как и любого нормального человека).

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

Вот именно. Проблема в том, что (IMHO) почти каждый программист почему-то считает, что он-то к "долбоклюям" не относится. ;)

йоксельт.е. "вали всё в кучу -- сериалайзебл вывезет"
(пусть сервер субд думаед -- он жалезный)

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

У тебя с этим какие-то проблемы? Одержимость мнимой низкой производительностью? ;)

сериализаторЕсли что, то на уровне одного запроса даже фантомы не проявятся, несмотря на RC промеж запросов.
Ну и что из того? Корректность-то этим не гарантируется.

сериализаторНо большинство отчетных систем на MSSQL вполне себе полагаются на авось-nolock, при котором не то, что закомиченные во время работы запроса данные могут проявиться, но закомиченные год назад и никем не трогаемые данные могут не попасть в отчет или задублироваться.
Да, это, к сожалению, так. :( А стоило бы уже полагаться на SNAPSHOT (в MS SQL его будет достаточно, если использовать только SERIALIZABLE для модификаций + SNAPSHOT для отчётов).

сериализаторИ ведь популярность этого говна вполне зашкаливает, так как определяется не столько идеалистическими теориями, но и технико-экономической целесообразностью.
Если у кого-то по факту не данные, а мусор, он может использовать NOLOCK сколько угодно. А большая часть "технико-экономической целесообразности", IMHO, состоит в том, что пользователи просто не подозревают , что в высококонкурентной среде они смотрят на мусор, а не на результат, а вот тем #удакам, которые всё это написали, экономически нецелесообразно признаваться в этом. ;) Я тоже на такое насмотрелся, и даже в случаях, когда пользователи ловят их за руку, они начинают спирать всё на то, что "СУБД глючит", и это почти всегда прокатывает. ;(

сериализаторНа примере очереди на подачу заявления неблагоприятный сценарий с конкуренцией:
RC+lock - выбрать окно обслуживания, постоять 5 минут и уйти.
Serializable - заполнить заявление наполовину, убедиться, что требуемое окно приема занято, начать заполнять заявление заново (ибо данные для заявления по мере заполнения изменились)... С ростом количества конкурентов, вероятность дойти до цели за обозримое время резко снижается, но при этом будут тратиться ресурсы бланков и чернил, снижая общую пропускную способность.

Вот блокировочник и выигрывает в таких ситуациях. ;)

йоксельPgSQLAnonymousВот блокировочник и выигрывает в таких ситуациях. ;)у дтлв, к коим вы принадлежать есть
СУБД работают для всех одинаково, дятел. ;)

йоксельпо уму сериалайзебл тоже от мудаков не спасёт -- они берут данное одной "короткой транзакцией", а данное, которому надлежит быть согласованному с первым -- кладут другой короткой транзакицей.
оппаньки

И что "оппаньки"?!

йоксельи делают круглые глаза -- типа всё же было сериалай,збл
и транзочки были короче миниюбок
от дятлов ничо не спасает. это константа.
Не спасает от чего именно?

Кстати, дятлы это как раз те, кто не использует SERIALIZABLE без веской причины. Для написания корректных транзакций на SERIALIZABLE достаточно обеспечить корректность транзакции самой по себе , и о других не нужно знать ничего . А на других уровнях нужно "последить за логикой собственного приложения", т.е. сторого говоря, знать, в каких транзакциях и как используются упомянутые в текущей таблицы, и подумать обо всех возможных взаимодействиях этих транзакций. Особенно это "интересно", если с базой работает несколько приложений, и какие-то написаны вовсе не тобой.

йоксельты уж определись, дятлушко
Кроме информации агентства ОБС, у тебя что-нибудь ещё есть, дерево?

йоксельу тебя короткие транзакции
или "корректные"
обычно одно с другим плёхо совместимо
природа весчей, вишь ли

Нет, не вижу. Сам придумал, как обычно?
Вот, например, из мурзилки ( https://ru.wikipedia.org/wiki/OLTP):
OLTP (Online Transaction Processing), транзакционная система — обработка транзакций в реальном времени.
Способ организации БД, при котором система работает с небольшими по размерам транзакциями,
но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.

В твоём мире какой-то свой, нескучный OLTP? ;)