powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / nested transaction vs savepoint
155 сообщений из 155, показаны все 7 страниц
nested transaction vs savepoint
    #34829473
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет Всем

Возник спор - вложенные транзакции (nested transaction) и точки сохранения (savepoint) это:
1) одно и то же, но названное по разному;
2) или существуют принципиальные факты различий в их поведении.
Интересует больше концепция, но будут интересны и реализации.

Что скажете ?

PS: Я за (1).

Удачи,
Дмитрий

--
AnyDAC ( www.da-soft.com ) - компоненты для доступа к Oracle, MySQL, MSSQL,
MSAccess, IBM DB2, Advantage DS, Sybase ASA, DbExpress, ODBC .
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829686
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мне кажется ни то ни другое

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

save tran фиксирует текущее состояние и откатываться тогда будет до него


или Вы другое имели в виду?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829735
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dmitry Arefiev : одно и то же.

SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ???
Транзакция или вся выполняется, или вся не выполняется. Всё остальное - не транзакция
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829762
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dmitry Arefiev
Это принципиально разные вещи.
Основное принципиальное отличие в том, что вложенные транзакции в классическом понимании транзакций - вообще невозможны.

Если есть одна транзакция (внешняя), внутри которой запускается еще одна (внутренняя), то ACID-ное durability требует, чтобы изменения, прибитые внутренним commit'ом были навсегда. Но тогда непонятно что должен делать случившийся позже внешний rollback, он ни оставить внутренние изменения не может (иначе это не rollback), ни откатить (иначе лесом пошло внутреннее durability).

Можно модифицировать понятие durability, внеся туда понятие "области видимости". Так, например, сделано в MS Access (интерсно, где еще?).
Можно ввести суррогатные сейвпоинты.
В простых случаях поведение и использование - идентично, в более сложных - нет.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829771
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох2 Dmitry Arefiev
Это принципиально разные вещи.
Основное принципиальное отличие в том, что вложенные транзакции в классическом понимании транзакций - вообще невозможны.Да, конечно.
Я имел в виду практическую сторону вопроса, ибо некоторые производители называют сейвпойнты вложенными тр-циями
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829931
Фотография GoldSquid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вложенных транзакций не бывает!

Код: plaintext
1.
-----------
 Dad el rublo! 
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829949
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ???


Это в Oracle :) Ну и наверное там где ЕСТЬ savepoint-ы
Так что таки НЕТ это не одно и то-же
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829954
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GoldSquidВложенных транзакций не бывает!

Код: plaintext
1.
-----------
 Dad el rublo! 


бывают
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34829958
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) hvlad SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ???


Это в Oracle :) Ну и наверное там где ЕСТЬ savepoint-ы
Так что таки НЕТ это не одно и то-же

если в rollback указано, что откатываться надо до savepoint-а
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830039
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) GoldSquidВложенных транзакций не бывает!

Код: plaintext
1.
-----------
 Dad el rublo! 


бывают

Ну, а если почитать:

Committing inner transactions is ignored by Microsoft® SQL Server™. The transaction is either committed or rolled back based on the action taken at the end of the outermost transaction. If the outer transaction is committed, the inner nested transactions are also committed. If the outer transaction is rolled back, then all inner transactions are also rolled back, regardless of whether or not the inner transactions were individually committed.

;)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830054
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохACID-ное durability требует, чтобы изменения, прибитые внутренним commit'ом были навсегда
Это про транзакции. А ACID для вложенных транзакций где-то описывается ?
Пьяный ЛохМожно модифицировать понятие durability, внеся туда понятие "области видимости".
Тогда это становится savepoint'ом, который nested transaction.
Пьяный ЛохВ простых случаях поведение и использование - идентично, в более сложных - нет.
Да, вот и хотелось бы увидить хотя бы один случай, где они разные ...
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830063
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin Gluk (Kazan) GoldSquidВложенных транзакций не бывает!

Код: plaintext
1.
-----------
 Dad el rublo! 


бывают

Ну, а если почитать:

Committing inner transactions is ignored by Microsoft® SQL Server™. The transaction is either committed or rolled back based on the action taken at the end of the outermost transaction. If the outer transaction is committed, the inner nested transactions are also committed. If the outer transaction is rolled back, then all inner transactions are also rolled back, regardless of whether or not the inner transactions were individually committed.

;)

Они НАЗЫВАЮТСЯ вложенными транзакциями ;)
Для Microsoft вообще характерно называть вещи не своими именами (из самыхблагих маркетинговых соображений разумеется)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830073
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Arefiev
Да, вот и хотелось бы увидить хотя бы один случай, где они разные ...

В Oracle savepoint неявно ставится перед каждым DML-оператором, что позволяет откатить этот оператор при возникновении ошибки. Попробуйте сделять то-же с помощью "вложенных" транзакций.

Кстати, в Oracle есть еще автономные транзакции, которые тоже не имеют никакого отношения к "вложенным"
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830089
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Попробуйте сделять то-же с помощью "вложенных" транзакций.
И в чем проблема ?
Gluk (Kazan)Кстати, в Oracle есть еще автономные транзакции, которые тоже не имеют никакого отношения к "вложенным"
Автономные транзакции скорее ближе к множественным транзакциям Interbase. Т.е. они скорее всего параллельные а не вложенные :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830131
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Arefiev Gluk (Kazan)Попробуйте сделять то-же с помощью "вложенных" транзакций.
И в чем проблема ?


В том чтобы откатить деятельность оператора, а не всю транзакцию
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830182
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)В том чтобы откатить деятельность оператора, а не всю транзакцию
Ну так откатывайте себе на здоровье, используя хоть вложенные транзакции, хоть точки сохранения. Только обрамляя каждый оператор блоком обработки исключительных ситуаций.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830189
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Насколько я понимаю, разница между savepoint и nested transactions заключается в том, что вложенные транзакции позволяют образуют независимый собственный домен блокировок, в то время, как точки сохранения используют один общий домен - родительскую транзакцию.
Кстати, существуют и такой подход, когда текстуально вложенная транзакция подтверждается независимо от статуса завершения объемлющей. На практике они используются практически в любой БД, применяющей UNDO/REDO протоколирование. В ARIES они называется nested top actions (NTA).
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830226
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Arefiev Gluk (Kazan)В том чтобы откатить деятельность оператора, а не всю транзакцию
Ну так откатывайте себе на здоровье, используя хоть вложенные транзакции, хоть точки сохранения. Только обрамляя каждый оператор блоком обработки исключительных ситуаций.

В MS SQL rollback откатит всю транзакцию, а не только вложенную
в этом и разница

2 teras

Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахар
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830339
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dmitry Arefiev
Это про транзакции. А ACID для вложенных транзакций где-то описывается ?
Нигде не описывается. Потому что не бывает ACID для вложенных транзакций. Конкретно - не бывает D. Бывает только "модифицированное D", т.е. для внешней транзакции закомиченные (внутренним комитом) изменения вполне дюрабильны, а для всего остального мира их еще не существует.

Тогда это становится savepoint'ом, который nested transaction.
Не становится.

Да, вот и хотелось бы увидить хотя бы один случай, где они разные ...
Напишите с использованием сейвпойнтов процедурину, которая обеспечивает атомарность, констистентность и изолированность (нужного уровня) для своих операций как при обычном вызове этой процедуры, так и при вызове внутри другой транзакции (в т.ч. с другим уровнем изоляции). И чтобы откат этой процедуры (в случае "вложенного" её вызова) не вызывал отката родительской транзакции, о которой вообще-то неизвестно ничего.
Когда напишете - тогда приходите.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830472
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dmitry Arefiev
З.Ы. Как было правильно сказано, сейвпоинты - это синтаксический сахар. Т.е. вроде как нельзя вложенные транзакции, но очччень хочеццо уметь "откатиться на чуть-чуть", причем сделать это более удобным способом, нежели выполнением обратных операторов. Всё, кроме как для "откатов на чуть-чуть" сейвпоинты больше ни для чего нужны быть не могут.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830481
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох2 Dmitry Arefiev
З.Ы. Как было правильно сказано, сейвпоинты - это синтаксический сахар. Т.е. вроде как нельзя вложенные транзакции, но очччень хочеццо уметь "откатиться на чуть-чуть", причем сделать это более удобным способом, нежели выполнением обратных операторов. Всё, кроме как для "откатов на чуть-чуть" сейвпоинты больше ни для чего нужны быть не могут.

Не надо с больной головы на здоровую. Я говорил про вложенные транзакции. savepoint-ы сахар вполне себе семантический и на роль вложенных транзакций никогда не претендовавший. У него типа свои задачи
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830489
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) Dmitry Arefiev
Да, вот и хотелось бы увидить хотя бы один случай, где они разные ...

В Oracle savepoint неявно ставится перед каждым DML-оператором, что позволяет откатить этот оператор при возникновении ошибки. Попробуйте сделять то-же с помощью "вложенных" транзакций.А в где они не ставятся ? :) С помощью "вложенных" это попробовать не получится, ибо их не бывает
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830502
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) hvlad SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ???


Это в Oracle :) Ну и наверное там где ЕСТЬ savepoint-ы
Так что таки НЕТ это не одно и то-жеCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так.
Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830546
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так.
Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует)

В Oracle savepoint-у НЕЛЬЗЯ делать commit, только rollback
если было бы можно - тогда действительно был бы маразм
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830623
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) hvladCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так.
Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует)

В Oracle savepoint-у НЕЛЬЗЯ делать commit, только rollback
если было бы можно - тогда действительно был бы маразмСлава Ларри, я в него верил :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830629
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad Gluk (Kazan) hvladCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так.
Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует)

В Oracle savepoint-у НЕЛЬЗЯ делать commit, только rollback
если было бы можно - тогда действительно был бы маразмСлава Ларри, я в него верил :)

дык
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830901
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохКогда напишете - тогда приходите.
Т.е. проблема только в том, что точки отката унаследывают уровень изоляции, а вложенные транзакции позволяют его установить другим. Т.к. то, что будет происходить в W, будет обладать атомарностью, консистентностью и изолированностью той же как и внешняя транзакция по отношению к другим транзакциями, включая "содержащую" транзакцию.

savepoint A;
try
........ <<< W
release savepoint A;
except
rollback to savepoint A;
raise;
end;

PS: Я пытаюсь уловить не "важность" фразы "вложенная транзакция", а реальный смысл и реальные отличия от точек сохранения.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34830946
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievPS: Я пытаюсь уловить не "важность" фразы "вложенная транзакция", а реальный смысл и реальные отличия от точек сохранения.

Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831049
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе
Скажем так - с их рассмотрение я связался при обсуждении dbExpress 5 :) Мне указали, что вложенные транзакции нужно поддерживать и мол это совсем другое, нежели точки сохранения.

Но можно долго пытаться увидеть в них модельную разницу. На практике - программисту доступны плоские транзакции и точки сохранения (автономные транзакции Oracle и синтаксис вложенных транзакций в MSSQL в расчет не беру). Последние могут быть вложенными.

Остальное все - обсуждение какого цвета была бы шерсть у вуглускра, если бы он существовал.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831059
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
точки сохранения не могут быть вложенными, а вложенных транзакций (в том понимании в котором вы их ищите) действительно не существует (да и не нужны они)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831112
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievНа практике - программисту доступны плоские транзакции и точки сохранения (автономные транзакции Oracle и синтаксис вложенных транзакций в MSSQL в расчет не беру). Последние могут быть вложенными.Ещё раз - нет никаких вложенных транзакций в MSSQL.
То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831172
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Gluk (Kazan)
Не надо с больной головы на здоровую. Я говорил про вложенные транзакции.
Вы, простите, говорили про какие вложенные транзакции? Про те, что MS называет вложенными? Так это не сахар, а самая обычная профанация, не имеющая никакого отношения ко вложенным транзакциям.

----------------------

2 Dmitry Arefiev
Т.е. проблема только в том, что точки отката унаследывают уровень изоляции, а вложенные транзакции позволяют его установить другим. Т.к. то, что будет происходить в W, будет обладать атомарностью, консистентностью и изолированностью той же как и внешняя транзакция по отношению к другим транзакциями, включая "содержащую" транзакцию.
Проблема в том, что сейвпоинт невозможно закоммитить. Он не самодостаточен, в отличие от транзакции.
А то, что MS называет вложенной транзакцией - невозможно откатить (не убив при этом все вышестоящее).
Что называют вложенными транзакциями в dbExpress5 - я не знаю.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831198
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе
Вообще-то "абстрактные вложенные транзакции не существующие в природе" - существуют. В MS Access, например :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831203
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad Dmitry ArefievНа практике - программисту доступны плоские транзакции и точки сохранения (автономные транзакции Oracle и синтаксис вложенных транзакций в MSSQL в расчет не беру). Последние могут быть вложенными.Ещё раз - нет никаких вложенных транзакций в MSSQL.
То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint.

Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ???
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831206
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan)Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе
Вообще-то "абстрактные вложенные транзакции не существующие в природе" - существуют. В MS Access, например :)

Там вообще транзакций не существует. Ни вложенных ни плоских.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831215
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох2 Gluk (Kazan)
Не надо с больной головы на здоровую. Я говорил про вложенные транзакции.
Вы, простите, говорили про какие вложенные транзакции? Про те, что MS называет вложенными? Так это не сахар, а самая обычная профанация, не имеющая никакого отношения ко вложенным транзакциям.


их родимых, от savepoint-ов хоть какая-то польза есть
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831216
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Там вообще транзакций не существует. Ни вложенных ни плоских.
Дададад.
Транзакции существуют только в оракле :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831252
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan)Там вообще транзакций не существует. Ни вложенных ни плоских.
Дададад.
Транзакции существуют только в оракле :)

ну почему же ? И в MS SQL и в DB2 и в Postgress-е
Это в акцесе недоразуменее какое-то (вы еще FoxPro вспомните, то-т фанаты порадюца)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831279
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladЕщё раз - нет никаких вложенных транзакций в MSSQL. То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint.
Я про то и говорю. Но коли их MS назвала вложенными, то пусть так и будут называться.
Gluk (Kazan)точки сохранения не могут быть вложенными, а вложенных транзакций (в том понимании в котором вы их ищите) действительно не существует (да и не нужны они)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
savepoint A;
try
  ....
  savepoint B;
  try
     ....
     savepoint C;
     try
       ....
     except
       rollback to savepoint C;
     end;
  except
     rollback to savepoint B;
  end;
except
  rollback to savepoint A;
end;
В том смысле вложенные, что откат к A удалит и B и C.
Я не искал вложенные транзакции, я скорее всего искал их отсутствие :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831283
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)ну почему же ? И в MS SQL и в DB2 и в Postgress-е
Бедный, бедный hvlad...
Его тоже без транзакций оставили...
Впрочем, если он попробует сказать, что они в FB есть, то тут же найдутся очередные фанаты, объевшиеся сырого мяса :)

Это в акцесе недоразуменее какое-то (вы еще FoxPro вспомните, то-т фанаты порадюца)
Фокс вспоминать не буду. Я его и не знал никогда.
В общем, не будем отклоняться от темы. Если хотите - упорствуйте в своей глупости, не буду мешать. В аксесе от этого не станет меньше транзакций, в том числе и вложенных.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831292
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Dmitry Arefiev
В том смысле вложенные, что откат к A удалит и B и C.
Для этого вообще не нужны B и C

Я не искал вложенные транзакции, я скорее всего искал их отсутствие :)
В MS SQL вложенных транзакций нет. Вы нашли отсутствие. Поздравляю :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831329
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох2 Dmitry Arefiev
В том смысле вложенные, что откат к A удалит и B и C.
Для этого вообще не нужны B и C
В том смысле, что при внешнем rollback поведение что сейвпоинтов, что вложенных транзакций, что псевдовложенных транзакций - идентично. Внутренности роли уже не играют.
Различия есть только при внешнем commit и внутреннем rollback.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831330
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лохфанаты, объевшиеся сырого мяса :)

Кстати, татарский бифштекс это немецкое блюдо. Во всяком случае мне так
сказали.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831334
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохВ MS SQL вложенных транзакций нет. Вы нашли отсутствие. Поздравляю :)
Спасибо. Надеюсь, что вложенных транзакций нет и в остальном реальном мире :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831339
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный ЛохЕсли хотите - упорствуйте в своей глупости, не буду мешать. В аксесе от этого не станет меньше транзакций, в том числе и вложенных.
но и больше их там не станет, обычный развод Лохов
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831342
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievСпасибо. Надеюсь, что вложенных транзакций нет и в остальном реальном мире :)
И не надейтесь :)
Они есть в аксесе.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831400
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) hvladЕщё раз - нет никаких вложенных транзакций в MSSQL.
То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint.

Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ???Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831413
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan)ну почему же ? И в MS SQL и в DB2 и в Postgress-е
Бедный, бедный hvlad...
Его тоже без транзакций оставили...
Впрочем, если он попробует сказать, что они в FB есть, то тут же найдутся очередные фанаты, объевшиеся сырого мяса :)

Это в акцесе недоразуменее какое-то (вы еще FoxPro вспомните, то-т фанаты порадюца)
Фокс вспоминать не буду. Я его и не знал никогда.
В общем, не будем отклоняться от темы. Если хотите - упорствуйте в своей глупости, не буду мешать. В аксесе от этого не станет меньше транзакций, в том числе и вложенных.

Я в курсе ваше заблуждения относительно наличия транзакций в акцесе, поэтому не буду спрашивать как там обеспечивается ACID
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831420
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad Gluk (Kazan) hvladЕщё раз - нет никаких вложенных транзакций в MSSQL.
То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint.

Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ???Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты.Соврал. Они ввели SAVE TRAN которые и есть нормальные сейвпойнты. А откатывать "вложенную тр-цию" нельзя. Какие молодцы :)

BOLIt is not legal for the transaction_name parameter of a ROLLBACK TRANSACTION statement to refer to the inner transactions of a set of named nested transactions
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831421
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad Gluk (Kazan) hvladЕщё раз - нет никаких вложенных транзакций в MSSQL.
То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint.

Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ???Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты.

угу, до начала основной транзакции, если склероз мне не изменяет
впрочем, если вы порадуете меня опровергающей ссылкой из BOL, признаю свою неправоту
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831426
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 hvlad
Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты.
Каким образом оно откатит "часть", позвольте полюбопытствовать?
Русским по белому же сказано:
It is not legal for the transaction_name parameter of a ROLLBACK TRANSACTION statement to refer to the inner transactions of a set of named nested transactions. transaction_name can refer only to the transaction name of the outermost transaction.

-------------

2 Gluk (Kazan)
Я тоже в курсе Ваших заблуждений, так что продолжайте упорствовать :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831553
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохРусским по белому же сказано:
[quot ]It is not legal for the transaction_name parameter of a ROLLBACK TRANSACTION statement to refer to the inner transactions of a set of named nested transactions. transaction_name can refer only to the transaction name of the outermost transaction.


Более того:

Naming multiple transactions in a series of nested transactions with a transaction name has little effect on the transaction. Only the first (outermost) transaction name is registered with the system . A rollback to any other name (other than a valid savepoint name) generates an error. None of the statements executed before the rollback is, in fact, rolled back at the time this error occurs. The statements are rolled back only when the outer transaction is rolled back.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831784
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gluk (Kazan)2 teras

Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахарПожалуй, я неудачно выразился. Имеется в виду владелец блокировок. Каждая транзакция удерживает набор блокировок. В случае с savepoint - все блокировки получаются от имени одной транзакции. В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой.
Насчет MS SQL не знаю - не пользую. Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34831820
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras Gluk (Kazan)2 teras

Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахарПожалуй, я неудачно выразился. Имеется в виду владелец блокировок. Каждая транзакция удерживает набор блокировок. В случае с savepoint - все блокировки получаются от имени одной транзакции. В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой.
Насчет MS SQL не знаю - не пользую. Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах.

Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832059
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией.
Это зачем?
Для всего остального мира эти две транзакции неотличимы (собственно, они обязаны выглядеть как одна, внешняя), а внутри - родительской транзакции нет смысла конкурировать с дочерней, равно как и наоборот, ибо ни к чему хорошему такая конкуренция не приведет, за исключением возможности дэдлока транзакции со своими собственными внутренностями.

Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой.
А это вообще как?
Если две транзакции вложены в третью, но не вложены друг в друга - то они исполняются последовательно. К тому моменту, как начинается вторая - первая уже завершена, и какие-либо специфические блокировки (отличные от "родительских") все сняты, даже если они были. Как транзакции могут между собой конкурировать, если они по времени не пересекаются?

Насчет MS SQL не знаю - не пользую.
А что пользуете?
Т.е. присоединяюсь к вопросу - это абстрактные рассуждения или нет?

Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах.
Совсем гениально.
Вложенные begin trans/commit trans - позволяют не заботиться о расстановке begin trans/commit trans?
Хлопаю одной ладонью.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832070
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Arefiev пишет:
> сохранения (savepoint) это:
> 1) одно и то же, но названное по разному;
> 2) или существуют принципиальные факты различий в их поведении.

Почти одно и тоже. Разница только в том, что во вложенных
транзакциях нельзя откатить транзакцию частично, а при наличии
savepoint - можно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832088
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad пишет:
> Транзакция или вся выполняется, или вся не выполняется. Всё остальное -
> не транзакция

Это классическая ACID-транзакция. Мы вроде бы говорим о двух ее расширениях.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832112
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras пишет:
> заключается в том, что вложенные транзакции позволяют образуют
> независимый собственный домен блокировок, в то время, как точки

В определении моделей транзакций про блокировки ничего нет,
потому как это уже реализация, а не модель.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832163
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivРазница только в том, что во вложенных
транзакциях нельзя откатить транзакцию частично
Давайте называть кошку кошкой.
Транзакцию вообще нельзя откатить частично. Если какие-то изменения были - то они были все. Вложенные транзакции (в нормальном, а не майкрософтовском понимании этого слова) затем и нужны, чтобы оформленной во вложенную транзакцию единицы работы - не было (при откате). То, что эту функциональность урезали и обозвали словом "сейвпоинт", а вложенной транзакцией обозвали какую-то белиберду, которую даже откатить нельзя - это п....ц какая заслуга майкрософта. Но не стоит за ними эту фигню повторять.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832213
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivво вложенных
транзакциях нельзя откатить транзакцию частично, а при наличии
savepoint - можно
Игра слов. И в том и в другом случае - можно откатить конкретный кусок изменений. Если использовать несуществующие-в-природе вложенные транзакции, то они позволяют откатить кусок изменений корневой транзакции, равный объему изменений вложенной транзакции. Т.е. с точки зрения корневой транзакции - точка сохранения и вложенная транзакция одна хрень, когда идет разговор об откате изменений.

Играя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ... Но их нет в природе ... А потому апельсин может быть соленым.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832231
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если использовать несуществующие-в-природе вложенные транзакции
Я категорически протестую против использования слов "несуществующие в природе" :)
Существующие, еще как существующие.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832247
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievИграя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ...
Я уже назвал еще одно отличие.
Вложенная транзакция - она в первую очередь транзакция, а уж потом вложенная.
Т.к. она транзакция - она может быть использована как самостоятельная единица. Сама, **я, без ансамбля. Завернули транзакцию в процедуру, вызвали её - получили нормальную, вполне обычную транзакцию. Вызвали эту же процедуру внутри другой транзакции - нормальная транзакция превратилась во вложенную.
А вот сейвпоинт - сам по себе использован быть не может. Он "чисто внутренний".
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832260
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Dmitry ArefievИграя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ...
Я уже назвал еще одно отличие.
Вложенная транзакция - она в первую очередь транзакция, а уж потом вложенная.
Т.к. она транзакция - она может быть использована как самостоятельная единица. Сама, **я, без ансамбля. Завернули транзакцию в процедуру, вызвали её - получили нормальную, вполне обычную транзакцию. Вызвали эту же процедуру внутри другой транзакции - нормальная транзакция превратилась во вложенную.
А вот сейвпоинт - сам по себе использован быть не может. Он "чисто внутренний".

То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Удобный способ получения deadlock-а в рамках одной сессии

P.S. До завтра
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832278
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Это разные вещи.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832339
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievВозник спор - вложенные транзакции (nested transaction) и точки сохранения (savepoint) это:
1) одно и то же, но названное по разному;
2) или существуют принципиальные факты различий в их поведении.
Я бы сказал, это похожие вещи с важным синтаксическим отличием, обуславливающим и отличие в поведении.

Для начала стоит определиться с тем, что есть вложенная транзакция. Для этого, с моей точки зрения, есть простой и удачный пример. Допустим, у нас есть классическая бизнес-функция перекладывания некоторой суммы со счета А на счет Б. Как мы понимаем, это транзакция, состоящая, условно, из start transaction [может быть неявного], пары update-ов и commit-а. Теперь: предположим, мы хотим реализовать бизнес-функцию "оплаты с комиссией", суть которой в том, что со счета А идет некая сумма на счет Б и 1% от этой суммы на счет В. Опять же мы понимаем, что это транзакция, и в то же время понимаем, что по сути это два вызова уже реализованной подпрограммы - вот мы и дошли до транзакции, состоящей из двух вложенных транзакций.

Итого: при соответствующем синтаксисе вложенных транзакций мы можем взять любую операцию, являющуюся "обычной транзакцией" и использовать ее как вложенную, то есть как часть другой транзакции. С сейвпоинтами мы такого не можем, поскольку синтаксис у них заведомо другой. Это, с моей точки зрения, есть основное отличие. Конечно, в конкретной реализации "вложенным транзакциям" могут дать другой, несовместимый синтаксис, но это будет довольно странно, имхо.

Можно, наверное, накопать и еще мелочей. Скажем, скрипт

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
create table svp as select rownum n from dual connect by level <=  1 ;
savepoint s;
update svp set n =  2 ;
savepoint s;
update svp set n =  3 ;
savepoint s;
update svp set n =  4 ;
rollback to savepoint s;
select n from svp;
rollback to savepoint s;
select n from svp;
rollback to savepoint s;
select n from svp;

поведет себя не совсем так, как я ожидал бы от вложенных транзакций.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832342
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохЭто разные вещи.
Совершенно разные.

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

Дискусии - большое спасибо, все прояснил для себя ! :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832505
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievА то, что вы мне предлагаете попробовать сделать при помощи "самостоятельной единицы" транзакции, так это уже не вложенная транзакция ...
Вы про что? Что именно я предлагаю попробовать сделать?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832732
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerпоскольку синтаксис у них заведомо другой. Это, с моей точки зрения, есть основное отличие.
Ну я думаю, семантическим и дополнительным практическим отличием вложенных транзакций от точек сохранения может быть то, что вложенные транзакции могут усилить уровень изоляции. В остальном, хоть убейте, но логической разницы не вижу. Лишь - разные термины, разный синтаксис ...

Вам как дельфийцу, может быть интересна отправная точка обсуждения :) Два варианта:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
oTX.BeginTransaction; // стартует транзакцию
try
  ....
  oTX.BeginTransaction; // создает savepoint
  try
    ...
    oTX.Commit; // делает release savepoint
  except
    oTX.Rollback; // делает rollback to savepoint
    raise;
  end;
  oTX.Commit; // делает commit транзации
except
  oTX.Rollback; // делает rollback тразанции
  raise;
end;

и другой ...

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
oTX.BeginTransaction; // стартует транзакцию
try
  ....
  oTX2 := oTX.BeginTransaction; // создает savepoint
  try
    ... << B
    oTX2.Commit; // делает release savepoint
  except
    oTX2.Rollback; // делает rollback to savepoint
    raise;
  end;
  oTX.Commit; // делает commit транзации
except
  oTX.Rollback; // делает rollback тразанции
  raise;
end;

Второй вариант предполагает наличие самостоятельных, вложенных транзакций. И тут возникает элементарная ситуация. Вот код в точке B берет и делает oTX.Commit/Rollback - т.е. завершает корневую транзакцию. Тогда все oTXi становятся инвалидными. И обращение к ним ведет к exception, а без них логика в полный рост не работает ...

Собственно я за схему (1). Коли имеется природа стека, то пусть такой и объектная модель и поведение будут.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832811
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Arefievможет быть то, что вложенные транзакции могут усилить уровень изоляции.
Вот это как раз очень спорный момент. Насколько я знаю, в некоторых серверах существует возможность менять уровень изоляции внутри транзации, но с моей точки зрения это - нонсенс. Вызвано это, насколько я понимаю, сугубо прикладными причинами (желанием прочитать в dirty read нечто, оставив остальной транзакции возможность работать в нормальном режиме) и желательно придумать более культурные пути решения тех же проблем. Ну а вложенная транзакция - как ни крути, "внутри", так что тоже получается некий нонсенс.

Вообще, вопрос изоляции в серверах, с моей точки зрения, недостаточно проработан. В частности, с моей точки зрения, для ХП необходим некий constraint типа "на каком уровне изоляции она может использоваться" - поскольку очевидно, что вызов на неподходящем уровне может привести к большим неприятностям.

Dmitry ArefievВ остальном, хоть убейте, но логической разницы не вижу. Лишь - разные термины, разный синтаксис ...
"На определенном уровне абстракции" разницы действительно нет. Но этот уровень, имхо, выше оптимального для разработчика.

Это технически разные механизмы со своими особенностями. Скажем, простой пример: если я из формы А вызываю форму Б, форма Б может обеспечивать возможность "частичного отката" как тем, так и другим механизмом. Однако, механизм вложенных транзакций подразумевает, что при нажатии OK форма Б закрывается, а с сейвпоинтами я могу сделать нечто вроде Apply (сохранить и продолжить редактирование). Пример конечно условный, но показывает "практическую разницу".

Dmitry ArefievВам как дельфийцу, может быть интересна отправная точка обсуждения
.....
Собственно я за схему (1). Коли имеется природа стека, то пусть такой и объектная модель и поведение будут.
Мне как дельфийцу ни один из этих вариантов особо не нравится.

В первую очередь, серверные концепции и доступ к ним из API - несколько разные вещи. Далее, мне как дельфийцу нужно следующее:

1. Возможность писать код в парадигме используемого сервера, не думая о специфике API. Если я коннекчусь к Oracle - я хочу иметь возможность написать start transaction / savepoint / savepoint / rollback to savepoint / savepoint / commit так, чтобы это выполнилось в точности так же, как непосредственная отправка таких команд на сервер.

2. Аккуратные, подчеркнуто отделенные обобщающие парадигмы API, которые я могу использовать по своему желанию и которые имеют инкапсулирванно разную реализацию для разных серверов. При этом они должны быть очень тщательно продуманы на отсутствие конфликтов с предыдущим пунктом.

Ну а имеющаяся природа стека далеко не так проста и однозначна.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 5 . 0  
Connected as test

SQL> create table svp as select  0  n from dual;

Table created

SQL> savepoint s0;

Savepoint created

SQL> update svp set n =  1 ;

 1  row updated

SQL> savepoint s1;

Savepoint created

SQL> update svp set n =  2 ;

 1  row updated

SQL> savepoint s0;

Savepoint created

SQL> update svp set n =  3 ;

 1  row updated

SQL> savepoint s2;

Savepoint created

SQL> update svp set n =  4 ;

 1  row updated

SQL> rollback to savepoint s0;

Rollback complete

SQL> select n from svp;

         N
----------
          2 

SQL> rollback to savepoint s2;

rollback to savepoint s2

ORA- 01086 : savepoint 'S2' never established

SQL> rollback to savepoint s0;

Rollback complete

SQL> select n from svp;

         N
----------
          2 

SQL> rollback to savepoint s1;

Rollback complete

SQL> rollback to savepoint s0;

rollback to savepoint s0

ORA- 01086 : savepoint 'S0' never established

Как видите, тут как бы это выразиться, не совсем стек.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832828
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 softwarer
Вызвано это, насколько я понимаю, сугубо прикладными причинами (желанием прочитать в dirty read нечто, оставив остальной транзакции возможность работать в нормальном режиме)
А почему Вы не рассмотрели обратную ситуацию - когда хочется "вложенную" часть выполнить на более высоком уровне изоляции? Тогда и "нонсенс внутри" не совсем нонсенс, и озвученная проблема "на каком уровне изоляции ХП может исполняться" не совсем проблема - ХП просто себе выставит нужный ей уровень, отработает, и преспокойно закоммитится.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832857
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gluk (Kazan)Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?И то и другое. Собственно, вопрос ведь вначале прозвучал абстрактно, так и отвечал. Сама модель - следствие чтения описаний алгоритмов, таких, как ARIES/NT и т.п. Что касается практики, то такой подход точно реализован в BDB, и, кроме, того встречался в документации на другие продукты.

MasterZivВ определении моделей транзакций про блокировки ничего нет, потому как это уже реализация, а не модель. Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

Пьяный ЛохДля всего остального мира эти две транзакции неотличимы (собственно, они обязаны выглядеть как одна, внешняя), а внутри - родительской транзакции нет смысла конкурировать с дочерней, равно как и наоборот, ибо ни к чему хорошему такая конкуренция не приведет, за исключением возможности дэдлока транзакции со своими собственными внутренностями. Вот, что пишет по этому поводу wikipedia : Changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed.
Или здесь : A parent transaction's actions are considered to conflict with its child's actions but not vice versa. Thus, it cannot access a resource if a child's lock prohibits the access. Thus, the child's lock wins.
Вот например, одно большое отличие в блокировщике - отпускание разделяемых блокировок до завершения родительской транзакции.

Пьяный ЛохЕсли две транзакции вложены в третью, но не вложены друг в друга - то они исполняются последовательно. К тому моменту, как начинается вторая - первая уже завершена, и какие-либо специфические блокировки (отличные от "родительских") все сняты, даже если они были. Как транзакции могут между собой конкурировать, если они по времени не пересекаются? Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении. Простейший пример - та же BDB.

Пьяный Лох Совсем гениально.
Вложенные begin trans/commit trans - позволяют не заботиться о расстановке begin trans/commit trans? Знаете, я как-то администрировал достаточно крупное приложение на oracle 7.3. Один из основных лозунгов у них был: "пишем всё на PL/SQL". Так вот - в нем каждая процедура была представлена в двух ипостасях - some_proc и some_proc_nc. Где some_proc, очевидно, вызывала some_proc_nc и commit. А некотрые процедуры еще и принимали специальный флаг, в зависимости от которого вызывали some_proc или some_proc_nc (и commit по необходимости). Не хочу обсуждать, насколько такой подход был оправданным (по меньшей мере он был систематичным), но при наличии такого счетчика, можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832887
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохА почему Вы не рассмотрели обратную ситуацию - когда хочется "вложенную" часть выполнить на более высоком уровне изоляции?
Еще раз. Для меня нонсенс - вообще желание менять уровни внутри одной транзакции, независимо от того, в какую сторону. Это приводит к идеологическому бардаку в и так не самой прозрачной картине многопользовательской работы. В частности, написанный Вами вариант означает среди прочего следующее: в одной и той же транзакции мы сначала читаем новые данные, потом повышаем уровень, делаем тот же селект - и читаем более старую версию тех же данных. Парадокс, однако.

Пьяный Лохи озвученная проблема "на каком уровне изоляции ХП может исполняться" не совсем проблема - ХП просто себе выставит нужный ей уровень, отработает, и преспокойно закоммитится.
Насколько я понимаю, вложенные транзакции в MSSQL в значительной степени аргументируются именно этой возможностью.

Однако, это всего лишь заметание мусора под кровать. Вместо "бардака внутри ХП" будет "бардак в вызывающем коде", разницы не особо.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832928
Фотография Dmitry Arefiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Я тут погуляв с собакой, увидел проблемы и в своих и в ваших рассуждениях.
Короче, буду думать - что-то все не слишком однозначно с API.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34832961
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry ArefievКороче, буду думать - что-то все не слишком однозначно с API.
Я бы предложил еще и обсудить в форуме дельфы или возможно в личной переписке с избранными :) Это действительно непростой вопрос, подойти к которому стоит очень аккуратно.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833090
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

Это как это? Как может родительская транзакция смотреть на вложенную в неё? Т.е. мы имеем такую последовательность
- Родительская транзакция
- Некие действия 1
- - Вложенная транзакция
- - Некие действия 2
- - Конец вложенной транзакции
- Некие действия 3
- Конец родительской транзакции

В каком месте тут родительская транзакция может смотреть на вложенную? Может Вы путаете с автономными транзакциями?
terasОчень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении.
Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833104
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer пишет:

> Вот это как раз очень спорный момент. Насколько я знаю, в некоторых
> серверах существует возможность менять уровень изоляции внутри
> транзации, но с моей точки зрения это - нонсенс. Вызвано это, насколько

Это только кажется, что нонсенс. На самом деле в некоторых СУБД
уровень изоляции можно менять даже для отдельной таблицы конкретного
запроса
. И в общем-то оно понятно, поскольку уровень изоляции
в конце концов лишь сила блокировок, накладываемых на обрабатываемые
данные.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833106
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer пишет:

> Насколько я понимаю, вложенные транзакции в MSSQL в значительной степени
> аргументируются именно этой возможностью.

В смысле, чтобы дать выполнится процедуре на любом нужном ей уровне транзакций ?
Тогда нет, вложенные транзакции могут и без процедур использоваться.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833165
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЭто только кажется, что нонсенс.


MasterZivНа самом деле в некоторых СУБД уровень изоляции можно менять даже для отдельной таблицы конкретного запроса .
Да. Я не стал об этом упоминать, дабы меня не заподозрили в желании поднять флейм о конкретных некоторых СУБД, но это безусловно пик бессмысленности. Можно помедитировать, например, над смыслом запроса, который дважды обращается к одной таблице с разными уровнями изоляции при этом.

Впрочем, это бред в любом случае, поскольку означает запрос на получение заведомо рассинхронизованных данных.

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

Так и здесь: из того, что нечто можно сделать (в частности, выполнить такой бардачный запрос) совершенно не следует, что это нужно делать.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833270
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.
Это, простите, какая-то чушь.
Вы, похоже, непонимаете, что изоляция - это защита (требуемого уровня) исполняемой транзакции от изменений во внешнем мире, а вовсе не защита внешнего мира от изменений в транзакции.
Фраза "ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой" в корне не верна. Запустите рядом транзакцию в Dirty Read - и ей будут видны еще незакомиченные изменения. Запустите рядом транзакцию в Serializable - и ей не будут видны даже и закомиченные.

Вот, что пишет по этому поводу wikipedia: Changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed.
Или здесь: A parent transaction's actions are considered to conflict with its child's actions but not vice versa. Thus, it cannot access a resource if a child's lock prohibits the access. Thus, the child's lock wins.
Что я могу ответить... Не читайте википедию.
По поводу того, что родительская транзакция в принципе не может смотреть на изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на изменения родительской. А раз уж "child's lock wins", то и вообще не нужны никакие блокировки между родительской и дочерней (ну либо в дэдлок войдём на ровном месте).

Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении.
Что это???
Все слова понятны, но общий смысл фразы мне недоступен.

Знаете, я как-то администрировал достаточно крупное приложение на oracle 7.3. ... Так вот - в нем каждая процедура была представлена в двух ипостасях - some_proc и some_proc_nc. Где some_proc, очевидно, вызывала some_proc_nc и commit. ... можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию.
Сделать проще можно было бы - именно через полноценные вложенные транзакции. Процедура имеет вначале Begin Trans, в конце Commit Trans (или Rollback, по ситуации), вызывай её откуда хочешь, и никакого геморроя со счетчиками невнятными. В аксесе я именно так и поступал, горя не знал.
Но Вы то говорили про майкрософтовскую реализацию, которая к вложенным транзакциям не имеет никакого отношения, и работу со вложенными Begin/Commit/Rollback ничуть не упрощает, а только усложняет. Т.е. можно в начале процедуры проверять счетчик, и в зависимости от его значения либо сейвпоинт ставить, либо транзакцию открывать, при успешном завершении процедуры либо ничего не делать (если был сейвпоинт), либо коммитить транзакцию (если была транзакция), а при неуспешном завершении либо откатывать до сейвпоинта (если он был), либо откатывать транзакцию. Но это - увеличение геморроя, а вовсе не его уменьшение.

-------------------------------

2 softwarer
Еще раз. Для меня нонсенс - вообще желание менять уровни внутри одной транзакции, независимо от того, в какую сторону.
А для Вас вообще желание менять уровни изоляции (не внутри еще какой-нибудь, а просто так) - не является ли нонсенсом?
Ну т.е. открыли соединение, запустили пачку каких-нибудь одиночных (нетранзакционных) select/insert/update/delete, на каком уровне изоляции - хз, на каком-то умолчальном, потом начали транзакцию с уровнем изоляции А, что-то там сделали, закоммитились, начали транзакцию с уровнем изоляции B, что-то там сделали, закоммитились, начали транзакцию с уровнем изоляции C, что-то сделали, закоммитились...
Эта последовательность действий - нонсенс (для Вас), или нет?
Если нет, то почему та же самая последовательность действий превращается в нонсенс как только её оборачиваем в транзакцию?
Если да, то выходит, что по хорошему надо вообще запретить менять уровень изоляции. Как один какой-то уровень изоляции выставили, так с ним и работают. Причем все. Выставили всем сериалайзбл, и все довольны :).
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833275
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу того, что родительская транзакция в принципе не может смотреть на незакомиченные изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на незакомиченные изменения родительской.
так корректнее.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833317
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Это разные вещи.

почему ?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833343
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Это разные вещи.

почему ?
По поведению.
Rollback внешней транзакции не откатит автономную, если я правильно понимаю.
В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833391
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras Gluk (Kazan)Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?И то и другое. Собственно, вопрос ведь вначале прозвучал абстрактно, так и отвечал. Сама модель - следствие чтения описаний алгоритмов, таких, как ARIES/NT и т.п. Что касается практики, то такой подход точно реализован в BDB, и, кроме, того встречался в документации на другие продукты.


вот тут не нашел каких-то феноменальных отличий от автономных транзакций

teras
MasterZivВ определении моделей транзакций про блокировки ничего нет, потому как это уже реализация, а не модель. Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.


Блокировки это один из механизмов обеспечения изоляции транзакций. Для версионников это особенно очевидно :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833430
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan) Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Это разные вещи.

почему ?
По поведению.
Rollback внешней транзакции не откатит автономную, если я правильно понимаю.
В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию.

Нет, родительская транзакция ждет завершения автономной и откатить ее не может по оппределению. Какие то тонкие различия могут быть в изоляции между родительской и вложенной, но по описанию BDB пока не уловил
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833431
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Для версионников это особенно очевидно :)

Вот только само существование версионников не для всех очевидно. Что
особенно неприятно, комитет по стандартам тоже в их числе. Отсюда в их
стандарте определение уровней изоляции через блокировки и феномены.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833436
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan) Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Это разные вещи.

почему ?
По поведению.
Rollback внешней транзакции не откатит автономную, если я правильно понимаю.
В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию.

Sorry, теперь включился
На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833444
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
Gluk (Kazan)Для версионников это особенно очевидно :)

Вот только само существование версионников не для всех очевидно. Что
особенно неприятно, комитет по стандартам тоже в их числе. Отсюда в их
стандарте определение уровней изоляции через блокировки и феномены.
Posted via ActualForum NNTP Server 1.4

Этим старым перичникам вообще мало что очевидно :(
Но Microsoft к примеры уже проголосовал за версионность, так что процесс идет
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833502
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Sorry, теперь включился
На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме.
Пардон, в чём каша то?
Код: plaintext
1.
2.
Begin Transaction
-- что то делаем
Rollback Transaction
Rollback откатывает всё, что было сделано между Begin и Rollback, и ничего больше не трогает.
Имхо - абсолютно логичное поведение было бы, если бы оно было таким.
Почему такая конструкция не должна откатить что-то внутри - не понимаю.
Почему такая конструкция должна откатывать что-то снаружи - не понимаю тем более.

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

Хотя ИМХО было бы более правильно оформлять эту "маленькую зелёненькую пирамидку" именно как отдельную самую обычную транзакцию, просто со необычным уровнем изоляции - "изолирована от всего, за исключением одной отдельно взятой рядом исполняющейся транзакции".
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833597
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833656
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Gluk (Kazan)
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает
Не вызывает.
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. То, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает.
Я как бы ни с чем и не спорю.
Просто если "маленькая зелёненькая пирамидка" по факту является независимой транзакцией со специфичным уровнем изоляции - то я бы предпочёл называть её именно независимой транзакцией со специфичным уровнем изоляции. Если её называют по другому - ничего страшного, главное не запутаться.
Если она по факту является чем-то другим - ну значит мои рассуждения на тему "как бы это покрасивше назвать" можно выкинуть в помойку, я не обижусь.

Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна
Необходимость "частичного" отката для Вас вопросов не вызывает? Надеюсь, что нет. Если да, то можно порассуждать на тему "зачем нужны сейвпоинты", но лучше не будем.
Необходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.

Если объединить "частичный" откат с "условным" коммитом - получится вполне съедобная вложенная транзакция.
Но у MS (в MS SQL Server) половина функционала (а именно условный коммит) - оставлена на Commit'е, а вторая половина (а именно частичный ролбек) - перекочевала в сейвпойнты.
В итоге получилась полная херня.

Самое непонятное, что эти же люди сделали Access, где "условный" Commit вполне нормально сосуществует с "частичным" Rollback.
(предлагаю воздержаться от оффтопа на тему Вашего неверия в существование транзакций в аксесе )
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833685
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.

Вот это вызывает вопросы. И в Oracle этого нет
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833700
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) Пьяный Лох
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.

Вот это вызывает вопросы. И в Oracle этого нет
Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833701
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохНеобходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.

Вызывает. Очень сильно вызывает :(
В Oracle 10g тоже наплодили всяких commit-ов которые не совсем commit-ы или совсем commit-ы, но только по субботам Лично меня это сильно печалит.

commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833710
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Gluk (Kazan) Пьяный Лох
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.

Вот это вызывает вопросы. И в Oracle этого нет
Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :)

не то процитировал :(

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


вот это ВЫЗЫВАЕТ вопросы
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833766
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Gluk (Kazan)
Пьяный ЛохНеобходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.

Вызывает. Очень сильно вызывает :(
А почему?
Вам так сильно хочется писать код в стиле упомянутого на прошлой странице, т.е.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Create Procedure SomeProc_nc
As
    Select ...
    Insert ...
    Update ...
    Delete ...

Create Procedure SomeProc
As
    Begin Transaction
    Exec SomeProc_nc
    Commit Transaction

Мне лично такое вовсе не нужно. Писать больше, думать потом еще, где какую вызвать... Ну его в пень.
Программист - животное ленивое.
Я вполне буду доволен, если смогу один раз написать
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Create Procedure SomeProc
As
    Begin Transaction
        Select ...
        Insert ...
        Update ...
        Delete ...
    Commit Transaction
и использовать эту процедурину там, где мне она нужна, а уж об уровнях вложенности пусть сервер думает, у него голова большой.
Собственно, в MS SQL Server я именно так и могу сделать. Я не могу безбоязненно в эту процедурину Rollback запихнуть :)

не то процитировал :(

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


вот это ВЫЗЫВАЕТ вопросы
Но ведь автономная транзакция имеет доступ к измененным, но, разумеется, еще незакомеченным данным "родительской"? Или я не прав?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833768
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу
ну а допустим надо какое-то действие откатить, но записать об этом в лог
для лога должен быть commit, для основного действия rollback

мне например не нравится что в MS SQL такое не сделать стандартными средствами
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833803
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper Gluk (Kazan)commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу
ну а допустим надо какое-то действие откатить, но записать об этом в лог
для лога должен быть commit, для основного действия rollback


Для того и были созданы автономные транзакции. Но автономная транзакция - независима от основной и полностью изолирована. Это просто способ выполнить какие-то транзакционные действия ЗА ПРЕДЕЛАМИ основной транзакции
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833813
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer пишет:

> Впрочем, это бред в любом случае, поскольку означает запрос на получение
> заведомо рассинхронизованных данных.

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

Тебя напр. не смущает, что управляя транзакцией вручную (multi-statement)
можно даже целостность транзакции нарушать ? Ну и что, целостность -
тоже абстракция, она с точки зрения конкретного приложения может
быть совершенно другой.

> :) Чтобы оценить смысл какого-то действия, нужно отвлечься от физики его
> реализации. Например, "в конце концов любые данные есть

Получишь скорость сферического коня в вакууме. Оно интересно,
но только с чисто теоретической стороны.

> Так и здесь: из того, что нечто можно сделать (в частности, выполнить
> такой бардачный запрос) совершенно не следует, что это нужно делать.

Тебе не нужно. Но ты - не все приложения на свете.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833826
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperмне например не нравится что в MS SQL такое не сделать стандартными средствами

Это можно и стандартными средствами, если вспомнить, что табличные переменные не подвержены действию откатов транзакций.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833882
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Тебя напр. не смущает, что управляя транзакцией вручную (multi-statement)
можно даже целостность транзакции нарушать ? Ну и что, целостность -
тоже абстракция, она с точки зрения конкретного приложения может
быть совершенно другой.


Целостность не нарушается ни на уровне операторов ни на уровне транзакции. Пока мы выполняем какие-то действия в транзакции, все наши действия - часть транзакции. Мы не можем нарушить ее целостность, мы можем только выполнить другую транзакцию. Сервер не обязан знать какой смысл вкладывает в выполняемые действия приложения
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34833905
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Create Procedure SomeProc
As
    Begin Transaction
        Select ...
        Insert ...
        Update ...
        Delete ...
    Commit Transaction
и использовать эту процедурину там, где мне она нужна, а уж об уровнях вложенности пусть сервер думает, у него голова большой.


Голова большой, но металлический :(
Логика вложенности процедур ой как далеко не всегда связана с логикой подтверждения транзакций. Так что разработчику включать голову ПОЛЕЗНО полюбому
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34835963
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuper teras вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

Это как это? Как может родительская транзакция смотреть на вложенную в неё? Т.е. мы имеем такую последовательность
- Родительская транзакция
- Некие действия 1
- - Вложенная транзакция
- - Некие действия 2
- - Конец вложенной транзакции
- Некие действия 3
- Конец родительской транзакции То, что здесь написано - никоим образом не противоречит тому, что сказал я. Зато уже вполне в состоянии улучшить конкурентность, за счет освобождения разделяемых ресурсов, занятых вложенной транзакцией. В общем случае возможна ситуация, когда один поток работает с несколькими транзакциями попеременно. Например:

- Родительская транзакция (P)
-- Запуск вложенной транзакции (T1)
-- Запуск вложенной транзакции (T2)
-- Действие в транзакции (T1)
-- Действие в транзакции (T2)
-- Действие в транзакции (T1)
-- Конец вложенной транзакции (T2)
-- Действие в транзакции (T1)
-- Конец вложенной транзакции (T1)
- Конец родительской транзакции(P)

SergSuperМожет Вы путаете с автономными транзакциями? Автономные транзакции - это те, что появились в Oracle (pragma autonomous_transaction)? Это несколько не то. Судя по тому, что про них пишут это NTA, про которые я уже писал.

terasОчень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении.
Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией[/quot] Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34835978
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна

Запись в логи - чтобы при откате транзакции не стирались ее следы из лога.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34835998
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный ЛохЭто, простите, какая-то чушь.
Вы, похоже, непонимаете, что изоляция - это защита (требуемого уровня) исполняемой транзакции от изменений во внешнем мире, а вовсе не защита внешнего мира от изменений в транзакции. Чушь, только потому, что не согласуется с вашими понятиями? Любопытно, одному не нравится упоминание блокировок, другому - простое описание (без учета dirty read). Как писать - математическими определениями? Оно и в самом деле понятнее будет?

Пьяный ЛохФраза "ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой" в корне не верна. Запустите рядом транзакцию в Dirty Read - и ей будут видны еще незакомиченные изменения. Запустите рядом транзакцию в Serializable - и ей не будут видны даже и закомиченные. Ну, dirty read - это да... Необсуждаемо. А насчет serializable... Кстати, ваша фраза реально верна только для версионника. Подробности из той же серии - ARIES/KVL и его разновидность ARIES/IM. Один из самых популярных методов реализации serializable. В случае с ним либо первая транзакция просто не сможет выполнить изменений, не говоря уж о коммите, либо вторая будет ждать завершения первой, еще до того, как прочитает данные в первый раз.

Пьяный Лох Вот, что пишет по этому поводу wikipedia: Changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed.
Или здесь: A parent transaction's actions are considered to conflict with its child's actions but not vice versa. Thus, it cannot access a resource if a child's lock prohibits the access. Thus, the child's lock wins.
Что я могу ответить... Не читайте википедию. Интересно, чем википедия не угодила? А как насчет приведенного университетского курса - тоже не читать? Мохана (автора серии алгоритмов ARIES), одного из самых влиятельных людей в истории БД, - тоже? Может заодно подскажете, что читать?

Пьяный ЛохА раз уж "child's lock wins", то и вообще не нужны никакие блокировки между родительской и дочерней (ну либо в дэдлок войдём на ровном месте). Причем тут deadlock? Возможность получения взаимоблокировки - свойство любого блокировщика. Кстати, представил - забавное зрелище. Программист, который при синхронном исполнении, в одном потоке, пишет программы с deadlock-ами. Мда...

Пьяный Лох Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении.
Что это???
Все слова понятны, но общий смысл фразы мне недоступен. Посмотрите тогда на BDB. Там транзакции явно указываются, а не связываются каким-то образом с контекстом исполнения. Из которого, при исполнении очередного выражения восстанавливается контекст.

Пьяный ЛохСделать проще можно было бы - именно через полноценные вложенные транзакции. Процедура имеет вначале Begin Trans, в конце Commit Trans (или Rollback, по ситуации), вызывай её откуда хочешь, и никакого геморроя со счетчиками невнятными. Вот-вот, именно про это я и написал. В таком подходе можно не заботиться о расстановке коммитов - существует единая и очень простая схема. Как там? "Хлопаете одной ладонью"? ;-)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34836129
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gluk (Kazan) вот тут не нашел каких-то феноменальных отличий от автономных транзакций Это потому, что там не хватает самого главного - поведения при откате родительской транзакции. Зато тут об этом написано: "However, even if a child transaction commits, if its parent transaction is eventually aborted, the child's changes are undone and the child's transaction is effectively aborted."

Там же написано и про блокировки - "The semantics of nested transactions are as follows. When a child transaction is begun, it inherits all the locks of its parent. This means that the child will never block waiting on a lock held by its parent. Further, locks held by two children of the same parent will also conflict." Здесь родительская транзакция не упоминается потому, что он не может обращаться к базе, пока существует хотя бы одна дочерняя. Могу предположить, что это связано либо с нежеланием разбираться с передачей прав на блокировки от родителя потомку в динамике, либо с нежеланием отслеживать действительное состояние транзакции для разборок с взаимоблокировками.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34836333
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras SergSuper
Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией?
По определению. Если уж википедия для Вас авторитет, то извольте:
Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными.
И соответственно все остальные Ваши рассуждения тогда ничего не стоят.

Ну сами подумайте: один поток делает А=1, другой паралельно делает А=2. В итоге результат работы оказывается непредсказуем
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34836613
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuper Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными. Что-же, этого вполне достаточно для ответа. Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются. Возникает вопрос - что тогда последовательные операции? Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая . Думаю, с этим трудно не согласиться. Как и с тем, что это определение никоим образом не противоречит понятию потоков. Собственно, единственное, что нужно сделать на практике, чтобы добиться последовательности исполнения операций разных потоков в одной транзакции, в соответствии с этим определением - например, использовать что-то наподобие мютекса, выделенного на транзакцию или гарантировать последовательность алгоритмически.
Кстати, опять же, это не только теория. Та же пресловутая BDB, насколько я помню, именно так работает с транзакциями. При этом она еще и возлагают требование соблюдения последовательности на программиста.
SergSuperНу сами подумайте: один поток делает А=1, другой паралельно делает А=2. В итоге результат работы оказывается непредсказуем Подумал. Здесь вы, говорите не о последовательных операциях, а, скорее, об упорядочивании операций или о непротиворечивости данных. Это всегда было и будет заботой программиста. Вы же не станете требовать предсказуемости значения операции A=random() mod 2 + 1? А это - аналог вашей модели.
SergSuperИ соответственно все остальные Ваши рассуждения тогда ничего не стоят. Знаете, у меня тоже нет особого желания доказывать .
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34836700
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая . Думаю, с этим трудно не согласиться. Как и с тем, что это определение никоим образом не противоречит понятию потоков. Собственно, единственное, что нужно сделать на практике, чтобы добиться последовательности исполнения операций разных потоков в одной транзакции, в соответствии с этим определением - например, использовать что-то наподобие мютекса, выделенного на транзакцию или гарантировать последовательность алгоритмически.
Кстати, опять же, это не только теория. Та же пресловутая BDB, насколько я помню, именно так работает с транзакциями. При этом она еще и возлагают требование соблюдения последовательности на программиста.
"После сборки тщательно обработать напильником"

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

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

Про random и непротиворечивость - на самом деле можно много спорить, но я думаю не стоит. Будем считать я этого не писал, тоже типа было лирическое отступление
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34836732
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuperЕсли нужно еще и что-то делать на практике - то, извините, противоречит. Т.е. то что Вы сделаете при соблюдении требования последовательности (кстати а где гарантия что не сделаете ошибки?) еще можно назвать транзакцией, но такую конструкцию, предоставляемую СУБД (не знаю как это правильно назвать) - нет. С точки зрения СУБД, последовательность операций - необходимое и достаточное требование для транзакции. Но вы правы, так, как подобные возможности нужны очень редко, вводятся дальнейшие ограничения чтобы сократить количество ошибок программиста. Кроме того, если они действительно требуются (а такое тоже бывает), можно реализовать достаточно неплохую аппроксимацию и в самой программе.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34837439
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Gluk (Kazan)
Голова большой, но металлический :(
Логика вложенности процедур ой как далеко не всегда связана с логикой подтверждения транзакций. Так что разработчику включать голову ПОЛЕЗНО полюбому
Дык этта... логика подтверждения транзаций не связана с логикой вложенности процедур. Она просто есть, эта логика подтверждения транзакций.

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

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

--------------------------------------------

2 teras
Чушь, только потому, что не согласуется с вашими понятиями?
Нет, чушь потому, что базируется на неправильной трактовке понятий.
Вы попытались привязать понятие изоляции к тому, видимы ли незакомиченные изменения другим транзакциям? Это - чушь. Изоляция - она совсем про другое. Она определяет "видимость" в совсем другую сторону, и с совсем другими (более многообразными) критериями, согласно которым изменения видны либо не видны.

Ну, dirty read - это да... Необсуждаемо.
Почему ж необсуждаемо? Очень даже обсуждаемо.
Уровень изоляции ничуть не лучше и ничуть не хуже остальных.
Сделал я два раза подряд "Select * From table1 Where field1=1", в первый раз получил 10 записей, во второй раз получил 9. Почему? Да и кто ж его знает. Может потому, что исполнял запросы в Read Uncommited, и кто-то сначала добавил запись, а потом откатился. Может потому, что исполнял запросы в Read Committed, а кто-то проапдейтил одну из записей так, что она теперь не попадает в условие выборки. Может потому, что исполнял запросы в Repeatable Read, а кто-то добавил запись.
Говорите, Read Uncommitted "необсуждаемо"? Тогда и Read Committed, и Repeatable Read, и Snapshot точно так же "необсуждаемо". Давайте в таком случае обсуждать только Serializable. BTW, и в этом случае по прежнему неверно Ваше утверждение о том, что изоляция это дескать когда никто другой не видит моих незакомиченных изменений.

А насчет serializable... Кстати, ваша фраза реально верна только для версионника.
Строго говоря, моя фраза для версионника не только не верна, а вообще неприминима. Потому что нет в версионниках Serializable, есть только неправильно обозванный Snapshot.

В случае с ним либо первая транзакция просто не сможет выполнить изменений, не говоря уж о коммите, либо вторая будет ждать завершения первой, еще до того, как прочитает данные в первый раз.
Это детали реализации. Несколько путей достижения одной и той же цели. А цель - не видеть (быть изолированным от) чужих изменений.
Если я не хочу слышать, что Вы мне говорите, то я могу заткнуть себе уши. А могу отрезать Вам язык. Требуемый результат достигнут, хоть и разными способами.
Вот так и СУБД, версионники просто не слушают других, блокировочники другим затыкают рот, в любом случае достигнута цель "не видеть чужие изменения".

Причем тут deadlock?
Именно при том. Это же Вы начали разговор про какие-то блокировки между внешней и внутренней транзакцией? Вот я и говорю Вам, что эти блокировки в принципе не могут быть нужны, ибо единственное к чему они могут привести - deadlock на ровном месте.

Вот-вот, именно про это я и написал. В таком подходе можно не заботиться о расстановке коммитов - существует единая и очень простая схема.
Вы писали не про это. Вы писали про майкрософтовскую реализацию, в которой как раз НЕ существует "единой и очень простой схемы".

teras SergSuper Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными. Что-же, этого вполне достаточно для ответа. Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются. Возникает вопрос - что тогда последовательные операции? Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая
Что-то Вы совсем в определениях запутались.
Как это "не идет речи о синхронности/асинхронности"? Именно об этом речь и идёт.
Операции либо выполняются последовательно, т.е. неодновременно, т.е. асинхронно, либо выполняются параллельно, т.е. одновременно, т.е. синхронно.

В том примере, который Вы привели, есть две транзации, являющие собой (по определению) единицу работы. В Вашем примере эти две единицы работы выполняются параллельно, а не последовательно. В этом ничего страшного нет, пусть исполняются параллельно. Все СУБД так умеют. Но как только параллельно выполняющиеся операции Вы пытаетесь засунуть в третью транзакцию, так тут же эта самая третья транзакция перестает быть транзакцией, ибо по определению там должно быть последовательное исполнение, а параллельного исполнения там быть не должно.

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

С точки зрения СУБД, последовательность операций - необходимое и достаточное требование для транзакции.
LOL
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34837512
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Выбегалло Gluk (Kazan)то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна

Запись в логи - чтобы при откате транзакции не стирались ее следы из лога.

см. "маленькие зеленые пирамидки" :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34838984
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох teras SergSuper Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными. Что-же, этого вполне достаточно для ответа. Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются. Возникает вопрос - что тогда последовательные операции? Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая
Что-то Вы совсем в определениях запутались.
Как это "не идет речи о синхронности/асинхронности"? Именно об этом речь и идёт.
Операции либо выполняются последовательно, т.е. неодновременно, т.е. асинхронно, либо выполняются параллельно, т.е. одновременно, т.е. синхронно.
teras таки не прав, но не по той причине, что вы назвали. Вы зря равняете неодновременность с асинхронностью, а параллельность с одновременностью. Это не так, но не будем в это вдаваться.

Чтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам. teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34839139
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 mir
Вы зря равняете неодновременность с асинхронностью
Чего???
Эти слова - одно и то же. Просто одно слово - русское, а другое - греческое.

Чтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам
Неверно.
Понятия синхронности/асинхронности (по-русски - одновременности/неодновременности) применимы к любым процессам. Последовательные операции, понятное дело, всегда и абсолютно асинхронны.

teras не прав
Да я ж не спорю :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34839673
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mirЧтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам. teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы. Вот. Об этом я и твержу - потоки, синхронность/асинхронность - это понятия из области теории операционных систем, а транзакция, последовательность операции и пр. - это из области теории баз данных. И это - принципиально разные вещи. Настолько разные, что ни одна более/менее серьезная книга по БД не проводит таких параллелей.
Да вы сами попробуйте реализовать что-то подобное базе данных с транзакциями, скажем - на основании массива, с построчными блокировками, транзакции представлены в виде отдельных объектов, и вы легко поймете, что эквивалентность потока и транзакции - это только удобство, но никак не необходимость - последовательного исполнения операций вполне достаточно.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34839678
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный Лох Если я не хочу слышать, что Вы мне говорите , то я могу заткнуть себе уши. А могу отрезать Вам язык. Требуемый результат достигнут, хоть и разными способами. Да, это заметно.
Пьяный ЛохВы попытались привязать понятие изоляции к тому, видимы ли незакомиченные изменения другим транзакциям? Это - чушь. Изоляция - она совсем про другое. Она определяет "видимость" в совсем другую сторону, и с совсем другими (более многообразными) критериями, согласно которым изменения видны либо не видны. Не надо смешивать понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) и уровня изоляции (декларирование условий, при которых для данной транзакции свойство изоляции будет выполнено). Изоляция определяется взаимодействем транзакций, в частности - незакоммиченными операциями. Вы все время говорите про понятие уровня изоляции.

Пьяный ЛохПочему ж необсуждаемо? Очень даже обсуждаемоSQL не определяет уровней изоляции DIRTY READ и SNAPSHOT. А версионность - это один из способов достичь уровня SERIALIZABLE.

Пьяный ЛохИменно при том. Это же Вы начали разговор про какие-то блокировки между внешней и внутренней транзакцией? Вот я и говорю Вам, что эти блокировки в принципе не могут быть нужны, ибо единственное к чему они могут привести - deadlock на ровном месте.
Возможность возникновения взаимоблокировок - это свойство системы, применяющей блокировки для обеспечения работы планировщика БД. Написать приложение без взаимоблокировок - задача программиста. Причем здесь deadlock?

Пьяный Лох Посмотрите тогда на BDB.
Благодарю. Вы написали достаточно, чтобы у меня не возникло ни малейшего желание смотреть на систему, где транзакциями называют что-то совсем на транзакции непохожее. Что сказать? Если вас пугают возможности - действительно, не стоит использовать инструмент в принципе.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34839732
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛП2 mir
Вы зря равняете неодновременность с асинхронностью
Чего???
Эти слова - одно и то же. Просто одно слово - русское, а другое - греческое.
Во-первых, ваш перевод с греческого неточен:
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211605,00.htmlasynchronous
-- In general, asynchronous (pronounced ay-SIHN-kro-nuhs, from Greek asyn-, meaning "not with," and chronos, meaning "time") is an adjective describing objects or events that are not coordinated in time .То есть смысл по гречески: « не привязанный ко времени », « не скоординированный во времени », а вовсе не «неодновременный».

Во-вторых, вы забываете, что одно дело -- общий, бытовой смысл, а другое дело -- специальный, относящийся к определённой предметной области. Если мы говорим о потоках и процессах, то мы должны говорить в соответствующей терминологии. Скажем, слово asynchronous имеет вовсе не одно, как вы считаете, а несколько разных значений:
http://onlinedictionary.datasegment.com/word/asynchronous 1. Not simultaneous; not concurrent in time; -- opposed to synchronous.
Syn: nonsynchronous, unsynchronized, unsynchronous.
[Webster 1913 Suppl.]

2. (Paleontology) occurring in different geologic times; -- of taxa/ synchronous
Syn: allochronic
[WordNet 1.5 +PJC]

3. chronologically misplaced; belonging to a different time or era
Syn: anachronic, anachronous, anachronistic
[WordNet 1.5 +PJC]

4. (Computers) occurring at different speeds in different computers connected by a data transmission link; -- said of methods data of transmission between computers.
Opposite of synchronous.
[PJC]

Как видим, нам нужно компьютерное, то есть 4-е значение. А это вовсе не «неодновременный».

Вот еще перевод с тем же смыслом:
WordNet (r) 2.1 (2005)asynchronous
adj 1: (digital communication) pertaining to a transmission technique that does not require a common clock between the communicating devices; timing signals are derived from special characters in the data stream itself [ant: synchronous]

Ещё:
Free On-line Dictionary of Computing (26 May 2007)asynchronous
<architecture> Not synchronised by a shared signal such as clock or semaphore, proceeding independently.
Ещё:
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211605,00.html1) In telecommunication signaling within a network or between networks, an asynchronous signal is one that is transmitted at a different clock rate than another signal. (plesiochronous signals are almost but not quite in synchronization - and a method is used to adjust them - and synchronous signals are those that run at the same clock rate.

2) In computer programs, asynchronous operation means that a process operates independently of other processes, whereas synchronous operation means that the process runs only as a result of some other process being completed or handing off operation. A typical activity that might use a synchronous protocol would be a transmission of files from one point to another. As each transmission is received, a response is returned indicating success or the need to resend. Each successive transmission of data requires a response to the previous transmission before a new one can be initiated.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34839778
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно)
О! Вторая попытка :)
Сравните её с первой Вашей попыткой: "свойство изоляции ... - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую."

Не надо смешивать понятия изоляции ... и уровня изоляции
Так я и не смешиваю. Это Вы смешиваете.
В первый раз за понятие изоляции Вы зачем-то выдали описание уровня изоляции Read Committed (да еще и неправильное).
Во второй раз за понятие изоляции Вы зачем-то выдали описание уровня изоляции Serializable

Вы все время говорите про понятие уровня изоляции.
Этой напасти подвержены именно Вы, увы :)

SQL не определяет уровней изоляции DIRTY READ и SNAPSHOT.
У Вас плохой SQL. У меня - прекрасно определяет :)
Уж не буду Вас поправлять по поводу того, что SQL - это язык, он не определяет, это его определяют.

А версионность - это один из способов достичь уровня SERIALIZABLE.
Отнюдь. Версионность - один из способов НЕ достичь уровня Serializable.

Причем здесь deadlock?
Для тупых еще раз.
Deadlock при том, что возможность его появления - единственное , что можно получить от упомянутых Вами бредовых блокировок между родительской и дочерней транзацией.
В пятый раз повторять не буду, уж извините.

Что сказать? Если вас пугают возможности
Да нет, что Вы. Они меня смешат :)

---------------------------

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

То есть смысл по гречески: «не привязанный ко времени», «не скоординированный во времени», а вовсе не «неодновременный».
Греческий смысл греческого слова Вы умудрились вычитать в толковом английском словаре? Браво

Как видим, нам нужно компьютерное, то есть 4-е значение.
Нет, не видим. Ну не видим мы data transmition link и прочих different speed.
Поэтому 4-ое значение - нам не нужно, хоть Вы его и считаете более компьютерным :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34839796
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
авторНе надо смешивать понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) и уровня изоляции (декларирование условий, при которых для данной транзакции свойство изоляции будет выполнено).
А вторая часть Вашего высказывания - еще более весёлая, чем первая.
Декларирование условий, значит?
Вы хотите сказать, что как только я ставлю уровень изоляции Read Committed, так тут же я этим уровнем изоляции декларирую, что если транзакция не будет видеть чужие незакомиченные изменения, то св-во изоляции будет выполнено, т.е. система обрет св-во "прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно"?

Декларация Read Committed как способ достижения всеобщего Serializable. Браво
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34840061
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный ЛохВо-первых, если уж Вы беретесь обсуждать тонкости перевода с русского на греческий и обратно, то не стоит использовать в качестве аргументов толковые словари для китайского языка, японского языка, немецкого языка, и для английского языка - тоже не стоит.
А вы-то почему беретесь обсуждать тонкости перевода с русского на греческий и обратно? Вашу речь оправдало бы одно: если бы вы привели обоснование своего перевода. Поэтому не стоит критиковать другого за иностранные источники, коли у вас нет ни иностранных, ни русских, никаких.
Пьяный Лох То есть смысл по гречески: «не привязанный ко времени», «не скоординированный во времени», а вовсе не «неодновременный».
Греческий смысл греческого слова Вы умудрились вычитать в толковом английском словаре? Браво В толковом английском словаре я вычитал английский смысл греческого слова. Не нравится мой перевод для "adjective describing objects or events that are not coordinated in time." -- дайте свой. А за браво спасибо.
Пьяный Лох Как видим, нам нужно компьютерное, то есть 4-е значение.
Нет, не видим. Ну не видим мы data transmition link и прочих different speed.
Поэтому 4-ое значение - нам не нужно, хоть Вы его и считаете более компьютерным :)Вы не видите исключительно из упрямства. Поймите, я и в мыслях не держал вас "уличать" в незнании и т.п., это не надо ни мне, ни вам. Просто подсказал, т.к. я довольно долгое время занимался теорией параллельных процессов и вычислений. Асинхронный режим взаимодействия двух процессов означает, что ни один из них не может делать предположений о моменте начала, моменте завершения и скорости выполнения другого процесса, то есть весь обмен данными должен вестись с помощью некотого внешнего по отношению к процессам буфера (и соответствующих дисциплин синхронизации). К реальной одновременности/неодновременности выполнения этих процессов асинхронность их взаимодействия не имеет никакого отношения.
Например, есть некая АЗС, в которую время от времени привозят цистернами бензин. И есть я, заправляющийся не этой АЗС. АЗС -- буфер. Подвоз бензина -- процесс 1. Моя заправка бензином -- процесс 2. Есть у процесса 2 зависимость от процесса 1? Есть, если бензин давно не везли, я не смогу заправиться. Есть у процесса 1 зависимость от процесса 2? Есть, ибо если не опустошать ёмкости АЗС, заправщику некуда будет вылить привезённый бензин.
Между процессами 1 и 2 взаимодействие есть, и оно асинхронное. Однако к реальной одновременности это взаимодействие не имеет отношения. Я могу заправляться в другое время, чем когда приезжает заправщик, а могу одновременно (забудем пока про технику безопасности, тут дело в принципе).
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34840250
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный ЛохЛадно, надоело. Объяснять свою точку зрения можно только тогда, когда собеседник хочет услышать. У вас же пока видно только стремление принизить собеседника, используя сарказм и личные нападки, видимо вы считаете, что вас это возвышает.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34840406
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 mir
А вы-то почему беретесь обсуждать тонкости перевода с русского на греческий и обратно?
Потому что я знаю, как переводится греческое слово synchronos на русский язык . Причем перевод на русский язык я знаю не из английского словаря.
Если Вы не знаете, как переводится греческое слово synchronos на русский язык - гугль в помощь, он работает.

Вы не видите исключительно из упрямства.
Разговор про транзакции - обычные, вложенные, автономные, последовательные, параллельные, какие угодно.
Нет разговора про transmission between computers и telecommunication signaling within a network.
Если Вы в разговоре про транзакции умудрились увидеть telecommunication signaling - то это даже не от упрямства, а скорее от аномалий зрения.

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

Подвоз бензина -- процесс 1. Моя заправка бензином -- процесс 2.
...
Между процессами 1 и 2 взаимодействие есть, и оно асинхронное.
Давайте чуть-чуть переформулируем, чтобы не плодить сущности без необходимости (заправки там всякие - ну зачем они нам).
Процесс 1 - уменьшение количества бензина в заправщике. Процесс 2 - увеличение количества бензина в Вашем бензобаке.
Идёт?

В таком случае можете и синхронную заправку сделать. Запрявляйтесь бензином прямо из бензозаправщика. Через большой резиновый шланг. Самый что ни на есть синхронный процесс. Из заправщика убыло 10 литров бензина (процесс 1), в Ваш бензобак прибыло 10 литров бензина (процесс 2), и процессы эти - одновременны, они начались в одно и то же время, и закончились в одно и то же время (с точность до несущественной длины большого резинового шланга)

Можете и асинхронно заправляться, конечно. Из заправщика бензин убывает (процесс 1), в Вашем бензобаке бензин прибывает (процесс 2), и процессы эти - неодновременны. Они либо неодновременно начались, либо неодновременно закончились, либо и то, и другое. То, что для обеспечения такой неодновременности требуется какой-то буфер (большая бочка aka АЗС) - это детали реализации.

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

------------------------------------------

2 teras
Ладно, надоело.
Жалко. Я надеялся, что Вы еще порадуете нас мудрыми определениями :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34841862
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛП2 mir
А вы-то почему беретесь обсуждать тонкости перевода с русского на греческий и обратно?
Потому что я знаю, как переводится греческое слово synchronos на русский язык . Причем перевод на русский язык я знаю не из английского словаря. Да, я тут поштудировал. Не спорю, synchronos переводится как одновременный, буквально будет «вместе-временный» ("syn" - вместе и "chronos" - время). Приставка a- переводится как не- и без-, но она, в отличие от anti- (против, вместо) означает не прямую противоположность свойству, а скорее отсутствие свойства. То есть «асинхронный» значит не «противоположный одновременности» (это было бы antisynchronos), а скорее «не обладающий свойством одновременности» или «не требующий одновременности». Русское же «неодновременный» гораздо категоричнее.

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

ЛПРазговор про транзакции - обычные, вложенные, автономные, последовательные, параллельные, какие угодно.
Нет разговора про transmission between computers и telecommunication signaling within a network. Речь зашла про потоки, насколько я помню. А потоки есть область параллельного программирования. Кстати, разве область параллельных транзакций не является частью области параллельной обработки информации? Является, конечно. А в этой области термины «синхронный» и «асинхронный» имеют очень четкие определения, основанные, смею вас уверить, вовсе не на буквальном переводе этих слов. И определения не совпадают с «одновременный» и «неодновременный».
ЛПЕсли Вы в разговоре про транзакции умудрились увидеть telecommunication signaling - то это даже не от упрямства, а скорее от аномалий зрения. А вы от каких аномалий умудрились не увидеть разговор про потоки? И от каких аномалий вы упёрлись в эти telecommunication signaling, не заметив в первом же определении просто «objects or events»? Или в другом определении просто «In computer programs»? Это ли не упрямство? :)


ЛПДавайте чуть-чуть переформулируем, чтобы не плодить сущности без необходимости (заправки там всякие - ну зачем они нам).
Процесс 1 - уменьшение количества бензина в заправщике. Процесс 2 - увеличение количества бензина в Вашем бензобаке.
Идёт? Нет. Здесь нет ничего лишнего. Без заправки (то есть буфера) асинхронное взаимодействие невозможно. Мне придется ждать, пока приедет заправщик, заправщику придется ждать, пока приеду я. А это совсем не то же самое. Поэтому дальнейшие ваши рассуждения несколько некорректны. Буфер не деталь реализации, а необходимое условие асинхронного взаимодействия.

Могу другой пример: если почтальон носит вам почту, пользуясь почтовым ящиком (он кидает, вы берёте), это асинхронное взаимодействие. Если он должен вручать вам почту лично в руки (как телеграммы), это синхронное. Это два принципиально разных подхода. Но асинхронность не означает обязательного требования неодновременности. Оно означает отсутствие зависимости от одновременности, необязательность одновременности.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34841987
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 mir
То есть «асинхронный» значит не «противоположный одновременности» (это было бы antisynchronos), а скорее «не обладающий свойством одновременности» или «не требующий одновременности».
Возражение принято.

Русское же «неодновременный» гораздо категоричнее.
Возможно, более корректно было бы использовать частицу "не" вместо приставки. Т.е. не "неодновременный", а "не одновременный".

А вы от каких аномалий умудрились не увидеть разговор про потоки?
Разговор про потоки я вполне увидел. Но в потоках я по прежнему не вижу "data transmition link between different computers" :)

И от каких аномалий вы упёрлись в эти telecommunication signaling, не заметив в первом же определении просто «objects or events»?
От аномалий "грязного чтения", вестимо :)

Нет. Здесь нет ничего лишнего. Без заправки (то есть буфера) асинхронное взаимодействие невозможно.
Взаимодействие - невозможно.
А асинхронное выполнение процессов - вполне.
Бензовоз, например, вполне может опорожняться прямо на землю, и процесс этот по времени будет совершенно независим от (т.е. "не одновременен с", "необязательно одновременен с") уже несвязанным процессом пополнения бака Вашего автомобиля.

Буфер не деталь реализации, а необходимое условие асинхронного взаимодействия.
Буфер - необходимая деталь реализации.
Может роль буфера АЗС выполняет. Может пятьдесят китайцев с вёдрами таскают бензин от заправщика к Вашему авто. Деталь необходимая, но не существенная.

Если же Вы настаиваете именно на взаимодействии бензовоза с АЗС и именно на взаимодействии АЗС с Вашим авто - тоже вариант. Но в этом случае есть два независимых взаимодействия двух ёмкостей с третьей (причем взаимодействия строго синхронных), а говорить о синхронности/асинхронности процессов изменения кол-ва топлива в никак не связанных между собой бензовозе и Вашем авто - вообще смысла нет.

Но асинхронность не означает обязательного требования неодновременности. Оно означает отсутствие зависимости от одновременности, необязательность одновременности.
Не спорю. Всё верно. Пусть асинхронность будет "отсутствием обязательной одновременности", в противопоставлении "антисинхронности", которая суть "обязательное отсутствие одновременности".

Однако же уже если имеется отсутствие одновременности - это значит, что уже есть и асинхронность, и "антисинхронность".

А вот teras, увидев в определении "последовательность действий" (т.е. явную их "не одновременность", и даже более строгую "неодновременность") - почему-то высказался, что дескать об синхронности/асинхронности речь не идёт. К чему и были мои возражения.

Ну и закончим, пожалуй, на этой радостной ноте :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34842109
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЛП2 teras
Ладно, надоело. Жалко. Я надеялся, что Вы еще порадуете нас мудрыми определениями :) У меня нет большого желания спорить с аргументами типа "я так привык". Так-что предлагаю желающим действительно разобраться самим этим заняться. Чтобы пояснить ситуации, объясняю, что deadlock между родительской и дочерней транзакцией не возможен (хинт - дочерняя транзакция наследует *все* блокировки родительской). Второе, "декларировать" поведение транзакции - это выражения мнения программиста об уровне изоляции, что может отражать или не отражать реальное поведение транзакции и ее требования к уровню изоляции. Третье - запустить MSDN и помедтировать на тему поиска "ODBC AND thread", читая подобные стати:

MSDNWhen creating a multithreaded application, you should be very careful in using multiple threads to manipulate the same object. For example, using the same CRecordset object in two threads might cause problems when retrieving data; a fetch operation in one thread might overwrite the data fetched in the other thread. A more common use of the MFC ODBC classes in separate threads is to share an open CDatabase object across threads to use the same ODBC connection, with a separate CRecordset object in each thread. Note that you should not pass an unopened CDatabase object to a CRecordset object in another thread.

Note
If you must have multiple threads manipulate the same object , you should implement the appropriate synchronization mechanisms, such as critical sections. Be aware that certain operations, such as Open, are not protected. You should be sure that these operations will not be called concurrently from separate threads. Удивительное дело - предлагают быть осторожными, делая fetch на одном и том-же объекте (HSTMT) из разных потоков! Смешная система, правда?
Вот еще, почему-же все таки в ODBC упоминается, что транзакция связана с соединением, но нигде не упоминается, что этот хендл нельзя использовать из разных потоков, или например, не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока?

Ну ладно, Microsoft, они ничего не понимают, так туде же и Oracle: OCI
Once spawned, threads run asynchronously with respect to one another. They can access common data elements and make OCI calls in any order . Because of this shared access to data elements, a synchronized mechanism is required to maintain the integrity of data being accessed.

The mechanism to manage data access takes the form of mutexes (mutual exclusivity locks), that is implemented to ensure that no conflicts arise between multiple threads accessing shared. In OCI, mutexes are granted for each environment handle.

The thread safety feature of the Oracle database server and OCI libraries allows developers to use the OCI in a multithreaded environment. Thread safety ensures code can be reentrant, with multiple threads making OCI calls without side effects. И что удивительно - можно вызывать функции в любом порядке, но опять же никаких ограничений на тему потоков . Тоже смешная система.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34842580
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
У меня нет большого желания спорить
А зачем тогда пришли? Уходили же вроде бы? Или Вам понравилось?
"Мужик, я не понял - ты охотник или педераст?" (с) анекдот

Чтобы пояснить ситуации, объясняю, что deadlock между родительской и дочерней транзакцией не возможен (хинт - дочерняя транзакция наследует *все* блокировки родительской).
На это я Вам уже отвечал.
Если нет правила "child's lock wins" - то будет дедлок, и нафиг такие блокировки не нужны.
Если есть правило "child's lock wins" - то дедлок разумеется невозможен. Дедлока не будет. Да и вообще ничего не будет - эти блокировки (между родительской и дочерней транзакциями) никем не будут замечены. Т.е. абсолютно никем. Родительская транзакция даже чисто теорерически не может упереться в дочерние блокировки (т.к. дочерняя уже закончена к тому моменту, когда код родительской исполняться продолжит), а если дочерняя транзакция упрётся в родительские - то она безусловно побеждает. Поведение ничуть не отличается от поведения при полном отсутствии блокировок между родительской и дочерней транзакцией. А если разницы нет - зачем платить больше? Опять получается, что нафиг такие блокировки не нужны.
Скажите, сколько раз нужно Вам надо это повторить, прежде чем до Вас дойдёт?

Второе, "декларировать" поведение транзакции - это выражения мнения программиста об уровне изоляции, что может отражать или не отражать реальное поведение транзакции и ее требования к уровню изоляции.
Ржунимагу
Как это "декларировать", но "может не отражать реальное поведение"?
Дескать садись ка ты, Иван Царевич, на своего серого волка, бери в руки свои декларации, и скачи к такой-то матери, не будет тебе Serializable, хоть ты обдекларируйся по самое нехочу, будет только Read Uncommitted.

Третье - запустить MSDN и помедтировать на тему поиска "ODBC AND thread", читая подобные стати:
Не читайте подобные статьи :)
Не потому, что статьи плохие, а потому, что Вы до них еще не доросли.
MFC-шная реализация библиотеки доступа к данным не обладает св-вом thread safety, однако же обязательно найдется очумелая башка, которая попробует в эту библиотеку долбиться одновременно с разных потоков. Для таких сказано русским по белому - "не делайте так, а то снег башка попадёт, а если уж вынуждены лезть в один объект с разных потоков, то синхронизируйтесь сами с собой, дабы не дай бог не исполнить чего-либо одновременно".

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

почему-же ... не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока?
Да на клиенте вызывайте Вы что хотите и как хотите, хоть в одном потоке, хоть в пяти, хоть последовательно, хоть параллельно. Если клиента не обрушите своими действиями, то и хорошо. На сервере то обёрнутые в транзакцию действия все равно будут выполняться последовательно (а иначе это не транзакция).
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34842953
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный Лох почему-же ... не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока?
Да на клиенте вызывайте Вы что хотите и как хотите, хоть в одном потоке, хоть в пяти, хоть последовательно, хоть параллельно. Если клиента не обрушите своими действиями, то и хорошо. На сервере то обёрнутые в транзакцию действия все равно будут выполняться последовательно (а иначе это не транзакция). Опа! Ну слава богу, дошло наконец, что транзакции не связаны с потоками ни на клиенте, ни на сервере, а последовательное исполнение операций - единственное требование.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34842981
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный ЛохMFC-шная реализация библиотеки доступа к данным не обладает св-вом thread safety, однако же обязательно найдется очумелая башка, По вам видно, что вы не читали. В той-же статье, буквально в предыдущем абзаце: "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes.". Лох , если хотите, что-то еще сказать - подкрепляйте ссылками на источники, где подтверждается то, о чем вы говорите, ну или хотя-бы читайте документацию.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34843290
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
Опа! Ну слава богу, дошло наконец, что транзакции не связаны с потоками ни на клиенте, ни на сервере, а последовательное исполнение операций - единственное требование.
Да мне-то на эти потоки пофигу. Это именно Вы потоки зачем-то приплели в попытке оправдать непоследовательное исполнение операций:
teras Пьяный ЛохЕсли две транзакции вложены в третью, но не вложены друг в друга - то они исполняются последовательно... Как транзакции могут между собой конкурировать, если они по времени не пересекаются? Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент.
terasВ общем случае возможна ситуация, когда один поток работает с несколькими транзакциями попеременно. Например:

- Родительская транзакция (P)
-- Запуск вложенной транзакции (T1)
-- Запуск вложенной транзакции (T2)
-- Действие в транзакции (T1)
-- Действие в транзакции (T2)
-- Действие в транзакции (T1)
-- Конец вложенной транзакции (T2)
-- Действие в транзакции (T1)
-- Конец вложенной транзакции (T1)
- Конец родительской транзакции(P)
Это ведь Ваши слова?
Если не понимаете того, что "приложение может выбирать" не имеет отношения к последовательному исполнению операций на сервере, и того, что "работать попеременно" применительно к двум единицам работы в принципе не может быть последовательным исполнением - то это Ваши проблемы с головой.
Не пытайтесь свои проблемы с головой на других валить :)

По вам видно, что вы не читали.
Чего я не читал?
В той-же статье, буквально в предыдущем абзаце: "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes
Офигительный multithreading support. Настолько офигительный, что прямо так и сказано (буквально в следующем абзаце, если верить Вам), что "might cause problems", и "you should be sure that these operations will not be called concurrently from separate threads".
Если это называется multithreading support, то я - солнце на небе, а горы состоят из пластилина. Не читайте таких статей :)

подкрепляйте ссылками на источники
Надо заметить, что Вы себя этим не утруждаете :)
А мне откровенно лениво лопатить msdn в поисках "предыдущего абзаца" непонятно какой статьи.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34844209
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПНу и закончим, пожалуй, на этой радостной ноте :)Ага :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845224
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В качестве дополнительной идеи к обсуждению тынц
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845245
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЛПДа мне-то на эти потоки пофигу. Это именно Вы потоки зачем-то приплели в попытке оправдать непоследовательное исполнение операций:
<...>
terasВ общем случае возможна ситуация, когда один поток работает с несколькими транзакциями попеременно. Например:

- Родительская транзакция (P)
-- Запуск вложенной транзакции (T1)
-- Запуск вложенной транзакции (T2)
-- Действие в транзакции (T1)
-- Действие в транзакции (T2)
-- Действие в транзакции (T1)
-- Конец вложенной транзакции (T2)
-- Действие в транзакции (T1)
-- Конец вложенной транзакции (T1)
- Конец родительской транзакции(P) Солнце мое, тут разговор шел о совсем других вещах - я с самого начала написал о том, что это МОЙ взгляд на то, что такое вложенные транзакции, зачем они нужны, и как их можно применять на практике. И совсем в этом вопросе не претендую на истину - потому, что, как не раз уже было отмечено, НЕТ устоявшейся концепции вложенных транзакций. В приведенном вами примере речь идет об ОДНОПОТОЧНОМ исполнении в БД наподобие BDB, или любой дргуой, реализующий в API подход в отношении мультипоточности в стиле BDB/ODBC/OCI (как описано выше) и вложенные транзакции, как предложил я.
Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой: teras SergSuperТ.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией? Теперь понятнее?
ЛППо вам видно, что вы не читали.Чего я не читал? Того, о чем говорите - описания MFC.
ЛПВ той-же статье, буквально в предыдущем абзаце: "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes
Офигительный multithreading support. Настолько офигительный, что прямо так и сказано (буквально в следующем абзаце, если верить Вам), что "might cause problems", и "you should be sure that these operations will not be called concurrently from separate threads".
Если это называется multithreading support, то я - солнце на небе, а горы состоят из пластилина. Не читайте таких статей :) Солнце небесное, только для вас - в этом абзаце, речь идет о совершенно типичных вопросах, возникающих при использовании потоков, совершенно ничего нового. И я никак не пойму, что вы так заботитесь о моем свободном времени? ;-)
ЛПподкрепляйте ссылками на источники
Надо заметить, что Вы себя этим не утруждаете :)
А мне откровенно лениво лопатить msdn в поисках "предыдущего абзаца" непонятно какой статьи. Я по меньшей мере указываю, откуда беру информацию, что дает возможность ее найти и проверить, а вы все приводите из головы. И насчет лопатить - это громко сказано. Отмечаем крыжик Technology: "C++ libraries (Native)", затем ищем фразу "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes" и видим эту статью первой в списке статей. Назывется "ODBC Classes and Threads (MFC)". Искать с применением фраз из прошлых постов - ни разу не сложнее, ну разве, что она будет второй в списке.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845250
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir ЛПНу и закончим, пожалуй, на этой радостной ноте :)Ага :) Зато цирк какой. Я все время вспоминаю фразу, недавно попавшуяся мне на глаза: "если вы спорите с идиотом, не забудьте, что он в этот момент делает то же самое".
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845267
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
shuklinВ качестве дополнительной идеи к обсуждению тынц Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Или у вас что-то другое на уме?

mir , у меня еще к вам вопрос есть - вы сказали, что я не прав, но так и не сказали в чем. Любопытно, все таки - о чем речь?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845278
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras shuklinВ качестве дополнительной идеи к обсуждению тынц Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions?
Да, если поддерживать в каждой транзакции не более одной вложенной одновременно
.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845559
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras shuklinВ качестве дополнительной идеи к обсуждению тынц Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Или у вас что-то другое на уме?

mir , у меня еще к вам вопрос есть - вы сказали, что я не прав, но так и не сказали в чем. Любопытно, все таки - о чем речь?Какой смысл вам обращаться к человеку, которого вы только что публично назвали идиотом?

А что до того, почему вы не правы -- я об этом писал сразу же: "teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы."

Вы читать не умеете?

Еще раз, вы писали: "Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются." Может, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845674
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mirА что до того, почему вы не правы -- я об этом писал сразу же: "teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы."

Вы читать не умеете? Видимо - нет. Точнее, не могу понять, в чем это расходится с моими утверждениями? Что вы понимаете говоря "последовательные операции"? Транзакции целиком или их составные операции? Я изначально утверждал, что элементарные операции в транзакции НЕ выполняются параллельно, но из этого не следует, что их нельзя инициировать ассинхронно. В чем я не прав?

mirМожет, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения. Что-же вы так испугались? Все же просто: вы не спорьте - просто объясните, в чем я ошибаюсь. Без хамства и переходов на личности. Потому что ни, то ни другое - ничего не доказывает. И если вам какие-то рассуждения показались неверными - может лучше обсудить почему, чем так, а?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845688
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklinВ качестве дополнительной идеи к обсуждению тынц

О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!

или Инвестора нашел ???
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845912
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34845977
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП ? Или вы знаете другой способ остановить подобное? Предложите, буду крайне признателен. Серьезно.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846394
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 teras
Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой:
Чего Вы врёте?

Было Ваше утверждение о том, что две транзакции, вложенные в третью, могут конкурировать между собой. Здесь.
Был мой вопрос о том, каким же это образом они могут конкурировать, если они исполняются последовательно и не пересекаются во времени. Здесь.
Был Ваш ответ, что дескать очень просто, не все СУБД связывают транзакцию с потоком, и некоторые позволяют что-то там выбирать. Здесь.
В ответ на это Ваше высказывание был вопрос SergSuper: "Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией". Здесь.

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

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

в этом абзаце, речь идет о совершенно типичных вопросах, возникающих при использовании потоков
Вопросы - да, соверешенно обычные. Необычно лишь то, что утверждается, что сделан mutlithreading support, при том, что весь multithreading support придется делать самому программисту, использующему MFC.

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

Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП? Или вы знаете другой способ остановить подобное?
А Вы ограничьте своё рвение в высказывании чуши. Тем самым избавите других от необходимости объяснять Вам, почему сказанное Вами является чушью, а самого себя избавите от необходимости трактовки этих объяснений в качестве "придирок и хамства".
Не хотите ограничивать своё рвение в деле высказывания чуши? Ваше право, продолжайте высказывать чушь. Только не обижайтесь тогда, если Вас как обоссавшегося щенка в эту чушь носом тыкать будут.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846415
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!
А почему в однопользовательской системе не может (или не должно) быть транзакций?
Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846508
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛП2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!
А почему в однопользовательской системе не может (или не должно) быть транзакций?
Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :)

Лох прав. Транзакция не зависит от количества пользователей.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846540
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛП2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!
А почему в однопользовательской системе не может (или не должно) быть транзакций?
Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :)

Ага, только здесь ботва все больше про изолированность в последнее время ;)
Да и на счет дюрабельности в его поделии тоже вопросы были
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846547
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сахават Юсифов ЛП2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!
А почему в однопользовательской системе не может (или не должно) быть транзакций?
Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :)

Лох прав. Транзакция не зависит от количества пользователей.

Вы на продвигаемый ПРОДУКТ смотрели ?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846558
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)
Вы на продвигаемый ПРОДУКТ смотрели ?

Качаю. :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846591
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Ага, только здесь ботва все больше про изолированность в последнее время ;)
Изолированность я не упомянул просто потому, что в однопользовательской системе она совершенно точно есть, её не надо обеспечивать, ни транзациями, ни чем другим :)
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846691
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras mir2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Освежу вашу память.

Теперь еще раз по теме. Попытайтесь понять, что если последовательность операций по определению должна выполняться последовательно (Op 1 -> Op 2 -> ... -> Op n ), то ни о каких параллельных потоках или процессах и речи быть не может. В начальный момент времени может выполниться только операция Op 1 . Op 2 начать выполнение не может, пока не завершилась Op 1 (см определение последовательного выполнения). И так далее. Ни в один момент времени ни одна операция не может начать выполнение, пока не завершилась предыдущая. А значит, в любой момент времени только одна операция из последовательности может выполняться. О каком же синхронном или асинхронном выполнении каких вообще потоков можно говорить?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34846740
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЛП2 teras
Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой:
Чего Вы врёте?

Было Ваше утверждение о том, что две транзакции, вложенные в третью, могут конкурировать между собой. Здесь.
Был мой вопрос о том, каким же это образом они могут конкурировать, если они исполняются последовательно и не пересекаются во времени. Здесь.
Был Ваш ответ, что дескать очень просто, не все СУБД связывают транзакцию с потоком, и некоторые позволяют что-то там выбирать.
Здесь.
В ответ на это Ваше высказывание был вопрос SergSuper: "Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией". Здесь. А что-ж вы не процитировали мой ответ ? О том, что до того момента "речь шла о другой крайности"? Очевидно, что другая крайность к "несколько потоков в одной транзакции" это - несколько транзакций в одном потоке. Если хотите простой пример такого - пожалуйста. Берем ODBC или OCI, в ОДНОМ потоке открываем ДВА соединения (оба ассоциируют транзакцию БД с соединением) и затем, в том-же самом потоке используем поочередно то первое, то второе соединение. Хотя такой подход требует особой осторожности в программировании, ни ODBC, ни OCI НЕ ограничивают в таком использовании. Где здесь потоки и причем здесь потоки?
И именно в том-же посте я и спросил о том, а почему, собственно, нельзя работать с одной транзакцией из РАЗНЫХ потоков. Это и стало веткой про потоки, ассинхронность и т.д.

ЛПТолько нафига ж Вы по прежнему игнорируете высказывание о том, что хоть скольки поточное у Вас исполнение - в Вашем примере транзакции по прежнему исполняются не последовательно (а "попопеременно")? Хотелось бы знать, что вы имеете в виду, говоря транзакции исполняются попеременно? То, что одна транзакция обязательно завершается, прежде, чем начнется другая (про это мы уже выяснили)? Или то, что элементарные операции, составляющие одну транзакцию выполняется последовательно? О чем я написал в первом-же посте на эту тему?

ЛПТранзакции вполне могут исполняться не последовательно, но только не внутри другой транзакции, ибо там не может быть никакого непоследовательного исполнения ничего вообще, и вложенных транзакций в частности. Вернулись на начало. Еще раз повторяю, что такая модель вложенных транзакций далеко не единственная, но она существует, причем не только в теории, но и на практике. Ссылку на BDB я уже приводил. Если она вам не нравится или не нужна - ваше дело, но это не значит, что это - чушь. В любом случае, мнению ребят из Беркли я доверяю больше, чем вашему, уж извините.

ЛП Я по меньшей мере указываю, откуда беру информацию
Вам известно значение слова "ссылка"? Если нет, то зачем Вы его употребляете в своей речи, и тем более требуете от других? Известно. Толковый словарь Orfo:

Ссылка (сущ):
1) Пребывание ссыльного на поселении.
2) Выдержка из текста или указание источника, на который ссылаются.

Я использую слово во втором значении. Кроме того, я знаю, что в компьютерном жаргоне есть ещё одно значение, в достаточной мере совпадающее со вторым.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34847000
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir teras mir2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Освежу вашу память. Спасибо за подсказку. Вы уж простите великодушно, если вы приняли это на свой счет. Да я и не заметил, где мы с вами спорили, да еще и настолько бурно, и не понял, каким боком эта фраза может относиться к вам? А написал я о моем споре с ЛП . Собственно, весь спор был моей ошибкой - не учел специфику пользователей .

mirТеперь еще раз по теме. Попытайтесь понять, что если последовательность операций по определению должна выполняться последовательно (Op 1 -> Op 2 -> ... -> Op n ), то ни о каких параллельных потоках или процессах и речи быть не может. В начальный момент времени может выполниться только операция Op 1 . Op 2 начать выполнение не может, пока не завершилась Op 1 (см определение последовательного выполнения). И так далее. Ни в один момент времени ни одна операция не может начать выполнение, пока не завершилась предыдущая. А значит, в любой момент времени только одна операция из последовательности может выполняться. О каком же синхронном или асинхронном выполнении каких вообще потоков можно говорить? Безусловно вы правы. Но вы напрасно проводите параллель между этой моделью и моделью транзакции в БД.

О том, приведенное мной что определение последовательности в БД, данное Ульманом, а не мной, не подразумевает упорядоченности, я уже упомянул . А значит, мы уже не укладываемся в ваше определение из за использованной вами зависимости между окончанием одной операции и началом другой (я правильно интерпретирую стрелочки?). Нетрудно представить, что это вполне применимо на практике - например, в ОДНОЙ транзакции мы обновляем данные в БД для РАЗНЫХ датчиков, каждый из которых идентифицируется первичным ключем, или вообще находятся в разных таблицах, время ожидания готовности датчика может изменяться, но не превышает некоторой известной величины. Пусть одна транзакция - требование архитектора приложения, и мы можем на него повлиять. Можно заметить, что в этом сценарии нам все равно в каком порядке пройдут эти операции, единственное, что нас интересует, это чтобы они выполнились все. Согласны? Кроме того, взаимодействие с внешним миром делает неэффективным синхронное исполнение операции опроса и обновления данных. Одно из возможных решений (конечно, есть и другие) - использовать нескольких потоков (по количеству датчиков) для выполнения опросов и писать данные раздельно в каждом потоке. Таким образом, часть укрупненной операции (считывание+запись) будет выполняться ассинхронно (считывание), часть - синхронно(запись). При таком решении можно говорить о потоках?
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34847501
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
terasСпасибо за подсказку. Вы уж простите великодушно, если вы приняли это на свой счет. Да я и не заметил, где мы с вами спорили, да еще и настолько бурно, и не понял, каким боком эта фраза может относиться к вам? А написал я о моем споре с ЛП . Ваш комментарий был ответом именно на моё сообщение, адресованное ЛП. Вы назвали нашу с ним мини-дискуссию цирком, и сравнили нас с идиотами. Как ещё это было понимать?

terasБезусловно вы правы. Но вы напрасно проводите параллель между этой моделью и моделью транзакции в БД.

О том, приведенное мной что определение последовательности в БД, данное Ульманом, а не мной, не подразумевает упорядоченности, я уже упомянул . Процитирую вновь то определение:
"Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными."

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

Ваши рассуждения о возможности распараллеливания операция транзакции я понимаю, но в этом случае надо менять определение транзакции. В последовательности операций всё просто, никакой внутренней синхронизации не надо. А если транзакция перестаёт быть последовательностью, она становится "обычной" параллельной программой, в которой должны использоваться те или иные примитивы (мьютексы, семафоры, рандеву...) для синхронизации параллельных частей.

Мне с этакой кашей работать бы не хотелось. И так проблем много, а еще заниматься параллельным программированием? Я знаю, что это такое, и сколько ошибок это несёт.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34847821
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mir terasСпасибо за подсказку. Вы уж простите великодушно, если вы приняли это на свой счет. Да я и не заметил, где мы с вами спорили, да еще и настолько бурно, и не понял, каким боком эта фраза может относиться к вам? А написал я о моем споре с ЛП . Ваш комментарий был ответом именно на моё сообщение, адресованное ЛП. Вы назвали нашу с ним мини-дискуссию цирком, и сравнили нас с идиотами. Как ещё это было понимать? Очень просто - вы же посмеялись (несколько саркастически) над тем, что происходит между мной и ЛП? (я так считаю потому, что что процитированный вами комментарий ЛП относился к нашей дискуссии) Вот я и присоединился к этому и высказал свое видение ситуации.

mirВаши рассуждения о возможности распараллеливания операция транзакции я понимаю, но в этом случае надо менять определение транзакции. Если хотите, я приведу определение из книги Ramakrishnan et all, Database Management Systems: "A transaction is defined as any one execution of a user program in a DBMS" (выделение автора). Как видите, очень расплывчатое определение. Причем, это вполне объяснимо: дело СУБД исполнять запросы в порядке их поступления (тут порядок важен по понятным причинам), а не налагать ограничения на то, в каком порядке эти запросы генерируются программой пользователя.

У Ульмана в упомянутой книге (Системы Баз Данных. Полный курс) в главе "Транзакции и SQL" (8.6) мельком упоминается последовательное (serially) исполнение операций в составе транзакций, а затем в примере "Последовательное исполнение операций" (8.6.1) приводится упомянутое мной определение последовательного исполнения(serially). Хотя в целом, в этой главе речь идет об условно-последовательном (serializable) исполнении транзакций , что, очевидно, представляет гораздо больший интерес для БД. Понимаете, что я хочу сказать?

mirМне с этакой кашей работать бы не хотелось. И так проблем много, а еще заниматься параллельным программированием? Я знаю, что это такое, и сколько ошибок это несёт. Не хочу - это совсем не тоже самое, что "не могу". Я ведь не призываю так делать без необходимости, речь идет о принципиальной возможности.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34864550
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Просматривал сегодня презентации с сайта "Transaction Processing
Concepts and Techniques" (это курс, который читали в Стенфордском
университете), и в главе
Transaction
Models
наткнулся на такое определение:

Nested Transactions.
* A nested transaction is a tree of transactions, the sub-trees of which
are either nested or flat transactions.

* Transactions at the leaf level are flat transactions. The distance
from the root to the leaves can be different for different parts of the
tree.

* The transaction at the root of the tree is called top-level
transaction, the others are called sub-transactions. A transaction's
predecessor in the tree is called parent; a sub-transaction at the next
lower level is also called a child.

* A sub-transaction can either commit or rollback; its commit will not
take effect, though, unless the parent transaction commits.
The rollback of a transaction anywhere in the tree causes all its
sub-transaction to roll back. This combined with the previous point is
the reason why sub-transactions have only ACI, but not D.

Commit rule : The commit of a sub-transaction makes its results
accessible to the parent transaction only. The sub-transaction will
finally commit (i.e. release its results to the outside world) if and
only if it has committed itself locally and all its ancestors up to the
root have finally committed.

Rollback rule : If a (sub-) transaction at any level of nesting is
rolled back, all its sub-transactions are also rolled back, independent
of their local commit status. This is applied recursively down the
nesting hierarchy.

Visibility rule : All changes done by a sub-transaction become
visible to the parent transaction upon the sub-transaction’s commit. All
objects held by a parent transaction can be made accessible to its
sub-transactions. Changes made by a sub-transaction are not visible to
its siblings.

Кстати, обратите внимание, как сформулировано правило видимости.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34864563
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras
Просматривал сегодня презентации с сайта "Transaction Processing
Concepts and Techniques" (это курс, который читали в Стенфордском
университете), и в главе
Transaction
Models
наткнулся на такое определение:

Nested Transactions.
* A nested transaction is a tree of transactions, the sub-trees of which
are either nested or flat transactions.

* Transactions at the leaf level are flat transactions. The distance
from the root to the leaves can be different for different parts of the
tree.

* The transaction at the root of the tree is called top-level
transaction, the others are called sub-transactions. A transaction's
predecessor in the tree is called parent; a sub-transaction at the next
lower level is also called a child.

* A sub-transaction can either commit or rollback; its commit will not
take effect, though, unless the parent transaction commits.
The rollback of a transaction anywhere in the tree causes all its
sub-transaction to roll back. This combined with the previous point is
the reason why sub-transactions have only ACI, but not D.

Commit rule : The commit of a sub-transaction makes its results
accessible to the parent transaction only. The sub-transaction will
finally commit (i.e. release its results to the outside world) if and
only if it has committed itself locally and all its ancestors up to the
root have finally committed.

Rollback rule : If a (sub-) transaction at any level of nesting is
rolled back, all its sub-transactions are also rolled back, independent
of their local commit status. This is applied recursively down the
nesting hierarchy.

Visibility rule : All changes done by a sub-transaction become
visible to the parent transaction upon the sub-transaction’s commit. All
objects held by a parent transaction can be made accessible to its
sub-transactions. Changes made by a sub-transaction are not visible to
its siblings.

Кстати, обратите внимание, как сформулировано правило видимости.
Posted via ActualForum NNTP Server 1.4

Чистой воды дебилизм.
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34864580
teras
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сахават Юсифов wrote:
>
> Чистой воды дебилизм.

В каком полку служили? ;-)

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

JIM GRAY is a Senior Researcher at Microsoft, working on scalable
computing. He worked on many database and transaction processing systems
at IBM, Tandem, Digital, and Microsoft. With Andreas Reuter, he
co-authored the book Transaction Processing Concepts and Techniques. He
recently received the ACM A.M. Turing Award for his contributions to
transaction processing.

ANDREAS REUTER is the Scientific Director of the European Media
Laboratory (EML) in Heidelberg and Dean of the School of Information
Technology at the International University in Germany at Bruchsal. He
has been an independent consultant, a Professor at Kaiserslautern and at
Stuttgart where he founded the Institute of Parallel and Distributed
High Performance Systems. He was Computer Science Dean and later
Vice-President of Stuttgart University.

PHIL BERNSTEIN is a senior researcher in the Microsoft Research Database
Group and an architect of the Microsoft Repository. His research is in
the areas of databases, particularly on repository systems (object
databases, information models, version and configuration management) and
transaction processing (concurrency control and recovery). He coauthored
the books Principles of Transaction Processing and Concurrency Control
and Recovery in Database Systems, and teaches at U. Washington.

DIETER GAWLICK is an architect in Oracle's Database Server development
team. He focuses on extending the database technology to support
messaging and EAI (Enterprise Application Integration).Before joining
Oracle, Dieter developed a workflow system at Digital, and worked on
high performance I/O technology at Amdahl.During his time at IBM, Dieter
developed OLTP and database technology with the focus on high
performance and high availability. Dieter is the inventor and architect
of IBM's IMS Fast Path

DAN HARKEY along with Robert Orfali and Jeri Edwards, is co-author of
the best-selling books,Client/Server Survival Guide and Client/Server
Programming with Java and CORBA.Dan also heads the CORBA/Java
distributed objects master's program and lab at San Jose State
University and is a distributed objects consultant for IBM.

GREG HOPE is an architect at Microsoft working on the COM+, MTS, and DTC
technologies (http://www.microsoft.com/com). Prior to joining
Microsoft's "viper" project, Greg built a variety of distributed OLTP
systems, including co-founding Prologic in 1984, and implementing PROBE
and Ovation, a PC based (MS-DOS / Windows NT) distributed TP monitor and
retail banking system in production at over 300 banks in 20 countries
(http://www.prologiccorp.com).

CHARLES LEVINE is a Program Manager in the SQL Server Performance Group
at Microsoft, focused on benchmark and ISV performance issues. Charles
has been active in the Transaction Processing Performance Council (TPC)
since 1989, contributing to the definitions of TPC-A, B, and C. For the
last four years, Charles has served as Chairman of the TPC.

C. MOHAN joined IBM Research in 1981. He was named an IBM Fellow in 1997
for contributions to transaction management. He is an IBM Master
Inventor with 32 patents. His research results are implemented in
numerous IBM and non-IBM products. He is the primary inventor of the
ARIES family of recovery and locking methods, and the industry-standard
Presumed Abort commit protocol.

SUSAN MALAIKA is a senior software engineer at IBM's Santa Teresa DB2
development group. She specializes in distributed DB2, stored
procedures, XML and the Web. Before joining DB2 in 1997, Susan was an
Internet specialist in the UK and initiated projects that provide Web
access to IBM systems. Susan also worked in the CICS transaction
processing development group in the area of recovery, long running
transactions, interfaces to database management systems, and distributed
applications.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
nested transaction vs savepoint
    #34866514
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teras
Сахават Юсифов wrote:
>
> Чистой воды дебилизм.

В каком полку служили? ;-)

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

JIM GRAY is a Senior Researcher at Microsoft, working on scalable
computing. He worked on many database and transaction processing systems
at IBM, Tandem, Digital, and Microsoft. With Andreas Reuter, he
co-authored the book Transaction Processing Concepts and Techniques. He
recently received the ACM A.M. Turing Award for his contributions to
transaction processing.

ANDREAS REUTER is the Scientific Director of the European Media
Laboratory (EML) in Heidelberg and Dean of the School of Information
Technology at the International University in Germany at Bruchsal. He
has been an independent consultant, a Professor at Kaiserslautern and at
Stuttgart where he founded the Institute of Parallel and Distributed
High Performance Systems. He was Computer Science Dean and later
Vice-President of Stuttgart University.

PHIL BERNSTEIN is a senior researcher in the Microsoft Research Database
Group and an architect of the Microsoft Repository. His research is in
the areas of databases, particularly on repository systems (object
databases, information models, version and configuration management) and
transaction processing (concurrency control and recovery). He coauthored
the books Principles of Transaction Processing and Concurrency Control
and Recovery in Database Systems, and teaches at U. Washington.

DIETER GAWLICK is an architect in Oracle's Database Server development
team. He focuses on extending the database technology to support
messaging and EAI (Enterprise Application Integration).Before joining
Oracle, Dieter developed a workflow system at Digital, and worked on
high performance I/O technology at Amdahl.During his time at IBM, Dieter
developed OLTP and database technology with the focus on high
performance and high availability. Dieter is the inventor and architect
of IBM's IMS Fast Path

DAN HARKEY along with Robert Orfali and Jeri Edwards, is co-author of
the best-selling books,Client/Server Survival Guide and Client/Server
Programming with Java and CORBA.Dan also heads the CORBA/Java
distributed objects master's program and lab at San Jose State
University and is a distributed objects consultant for IBM.

GREG HOPE is an architect at Microsoft working on the COM+, MTS, and DTC
technologies (http://www.microsoft.com/com). Prior to joining
Microsoft's "viper" project, Greg built a variety of distributed OLTP
systems, including co-founding Prologic in 1984, and implementing PROBE
and Ovation, a PC based (MS-DOS / Windows NT) distributed TP monitor and
retail banking system in production at over 300 banks in 20 countries
(http://www.prologiccorp.com).

CHARLES LEVINE is a Program Manager in the SQL Server Performance Group
at Microsoft, focused on benchmark and ISV performance issues. Charles
has been active in the Transaction Processing Performance Council (TPC)
since 1989, contributing to the definitions of TPC-A, B, and C. For the
last four years, Charles has served as Chairman of the TPC.

C. MOHAN joined IBM Research in 1981. He was named an IBM Fellow in 1997
for contributions to transaction management. He is an IBM Master
Inventor with 32 patents. His research results are implemented in
numerous IBM and non-IBM products. He is the primary inventor of the
ARIES family of recovery and locking methods, and the industry-standard
Presumed Abort commit protocol.

SUSAN MALAIKA is a senior software engineer at IBM's Santa Teresa DB2
development group. She specializes in distributed DB2, stored
procedures, XML and the Web. Before joining DB2 in 1997, Susan was an
Internet specialist in the UK and initiated projects that provide Web
access to IBM systems. Susan also worked in the CICS transaction
processing development group in the area of recovery, long running
transactions, interfaces to database management systems, and distributed
applications.
Posted via ActualForum NNTP Server 1.4

Да глубоко наплевать кто они там.
Вложенные транзакции и дерево транзакций - фигня. Это уже не транзакции а синхронизаторы.
...
Рейтинг: 0 / 0
155 сообщений из 155, показаны все 7 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / nested transaction vs savepoint
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]