эттаPgSQLAnonymous,
у вас ус отклеился

у вас там таблички N непришейкобылехвост. [стюдент рука--лицо ]

Там написано , зачем они нужны, стюдент. ;)

эттаи да -- в пж при сериалайзебл будет откат второй

И это правильно.

эттарезюме -- те, кто не умеют писать серверную логику [полк их надысь пополнился випросом] -- хотят сериалазебла, чтобы клиентская реализация чисто серверного функционала хоть как-то ползала.

кто умеет -- пишут инкрементальную, а не агрегатную логику на сервере, и требуют именно readcommited-а, а не маргинальных снапшотов и т.п.

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


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

эттаPgSQLAnonymous,
так, как хочется стюденту, "должно быть" при read commited
а при serializable д.б. ошибка изоляции, как оно и происходит в пж

С чего ты взял, что мне так хочется?! Ты вообще читать умеешь, стюдент?!
Так я повторю так, чтоб ты увидел:

PgSQLAnonymous
И это правильно.



эттаа птичка тут продемонстрировала банальный repeatable read
Таки да. ;)

hvladPgSQLAnonymousПолучиться-то должно было так:Читаем что такое снапшот. 3 раза каждый день на ночь.

Обожемой, ты же даже не понял.
Читаем, что такое SERIALIZABLE, хоть 3 раза каждый день на ночь.

[quot этта]PgSQLAnonymous<>
обусловленный 2--мя ошибками "архитектора" -- кривым дизайном (с пересекающимся в конкурентной работе с аггрегирующими сущностями) и неверным уровнем изоляции (который с таким дизайном вообще не ползает, не то, чтобы трепыхаться). я этот дизайн ещё могу оживить. Будет ползать с очередями. Хотя он и левый. Вы -- никогда.

А покажи-ка "правый" дизайн для этой задачи, умник. Болтать --- не мешки таскать.


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

hvladPgSQLAnonymousОбожемой, ты же даже не понял. Ты таки не видишь в своём собственном примере тупой ошибки с расстановкой коммитов ? Обожемой (ц)
Никакой ошибки там нет . Это провоцирующий тест на сериализацию, который InterBase провалил .
Что будет в настоящей ACID-СУБД, тебе уже показали на примере PostgreSQL. Я бы посоветовал перечитывать, пока не дойдёт.

hvladpkarklinпропущено...
MS SQL.Т.е. там не будет дедлока при "перекрёстных" writes ? Позвольте не поверить :)
Или мы снова говорим о разном.
Да (кажется), там будет DEADLOCK, и это, опять-таки, правильно .
А InterBase просто тихо покоцал данные, и это то, чего не должно быть.

dimitrPgSQLAnonymousв настоящей ACID-СУБД
оставьте этот пафос, ей богу. Поддержка SERIALIZABLE и ACID вещи ортогональные.

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

dimitrИли может вспомним, что ваша "настоящая" СУБД до 2011 года была "ненастоящей" и вовсю баловалась "подменой терминов"?
Да была, да, баловалась. Я так подозреваю, что это было тупо содрано с некоторой СУБД, на которую PostgreSQL пытался быть похожим.
И что из того? Некоторые-то до сих пор "ненастоящие" и балуются.

hvladPgSQLAnonymous,

последняя попытка тебе образумиться:
- в момент старта каждой тр-ции в таблицах A и B было по 1-ой записи
- соотвественно инсерты видели по одной записи и позже вставили единицы, ибо это снапшот - он не может видеть
чужих изменений по-определению
- т.к. ты коммитишь первый инсерт до того, как выполнить второй инсерт, то конкуренции в твоём тесте нет вообще, ноль
- если сделать insert (1), insert (2), commit(1), commit (2), то insert (2) будет ждать commit(1) и, есс-но, вставит всё равно 1,
ибо в момент старта тр-ции (2) в таблице была 1 запись

PS То, что ты выдаёшь за единственно правильное, в IB\FB достигается с READ COMMITTED + RESERVING, но это я тут жевать не намерен.
Последняя попытка тебе образумиться: ты утверждал, что этот "SNAPSHOT TABLE STABILITY" --- это SERIALIZABLE.
В SERIALIZABLE должен был получиться один из двух указанных результатов. Тест показал, что это не так . Следовательно, "SNAPSHOT TABLE STABILITY" --- это не SERIALIZABLE , и все твои объяснения к делу не относятся.

Dimitry Sibiryakovэттаоткат 100500 конкурентов выше по ветке
Считаем на пальцах: пусть транзакция у анонимуса идёт 10 минут (иначе 100500 конкурентов
ну никак не накопятся), пусть он заставил из сериализоваться. Тогда последний конкурент
дождётся своей очереди на получение денег аккурат так через 10050000 минут. Умрёт от
старости он, пожалуй, гораздо раньше.

То есть ссылки на статистику NASDAQ и объяснения ты просто проигнорировал (потому что в твою картину мира они не укладываются)?

Dimitry SibiryakovPgSQLAnonymousПоддержка SERIALIZABLE --- это _обязательный_ компонент ACID, потому
что он обеспечивает свойство ISOLATION.
А вот нефиг читать комиксы в сокращённом варианте. Читай полную статью:
http://en.wikipedia.org/wiki/Isolation_(database_systems)

О, вот и ссылки на мурзилку появились. ;) Кстати, где ты там это вычитал?
Если тебе так нравится этот журнал, я оттуда поцитирую http://en.wikipedia.org/wiki/ACID :
The isolation property ensures that the concurrent execution of transactions results in a system state
that would be obtained if transactions were executed serially, i.e., one after the other.

Dimitry SibiryakovЯ их проигнорировал, поскольку во-первых, ты их не привёл, а во-вторых, там транзакции не длятся по 10 минут.


Во-первых:
PgSQLAnonymousКороче говоря, в некоторых условиях у достаточно крупного брокера тысячи транзакций могут пересечься.
Или все проблемы с конкурентным доступом нужно решать их отрицанием? ;)

Кстати, вот можно оценить объёмы транзакций на бирже: http://www.nasdaqtrader.com/Trader.aspx?id=DailyMarketSummary

И это только сделки, заявок (которые используются в моём примере) за день делается гораздо больше.

Во-вторых, в этом примере ни одна транзакция не длится по 10 минут.

Dimitry SibiryakovPgSQLAnonymousВо-вторых, в этом примере ни одна транзакция не длится по 10
минут.
А теперь берём цифры по ссылке, делим количество сделок на количество брокеров, а потом на
длину рабочего для и получаем 38 сделок в минуту на брокера. Где там 100500 откатов?

Попробую в третий раз:
PgSQLAnonymousИ это только сделки, заявок (которые используются в моём примере) за день делается гораздо больше.


Dimitry SibiryakovКстати, строгого контроля овердрафта там тоже нет, так что счёт брокера вообще не является
конкурентным ресурсом.

Почему ты в этом уверен?