|
|
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Привет Всем Возник спор - вложенные транзакции (nested transaction) и точки сохранения (savepoint) это: 1) одно и то же, но названное по разному; 2) или существуют принципиальные факты различий в их поведении. Интересует больше концепция, но будут интересны и реализации. Что скажете ? PS: Я за (1). Удачи, Дмитрий -- AnyDAC ( www.da-soft.com ) - компоненты для доступа к Oracle, MySQL, MSSQL, MSAccess, IBM DB2, Advantage DS, Sybase ASA, DbExpress, ODBC . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 20:13 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
мне кажется ни то ни другое если вы пишите вложенные транзакции, то при откатывании в любом месте откатыватся будет всё, независимо от того, что какие-то вложенные транзакции завершились save tran фиксирует текущее состояние и откатываться тогда будет до него или Вы другое имели в виду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 22:45 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Dmitry Arefiev : одно и то же. SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ??? Транзакция или вся выполняется, или вся не выполняется. Всё остальное - не транзакция ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 00:02 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Dmitry Arefiev Это принципиально разные вещи. Основное принципиальное отличие в том, что вложенные транзакции в классическом понимании транзакций - вообще невозможны. Если есть одна транзакция (внешняя), внутри которой запускается еще одна (внутренняя), то ACID-ное durability требует, чтобы изменения, прибитые внутренним commit'ом были навсегда. Но тогда непонятно что должен делать случившийся позже внешний rollback, он ни оставить внутренние изменения не может (иначе это не rollback), ни откатить (иначе лесом пошло внутреннее durability). Можно модифицировать понятие durability, внеся туда понятие "области видимости". Так, например, сделано в MS Access (интерсно, где еще?). Можно ввести суррогатные сейвпоинты. В простых случаях поведение и использование - идентично, в более сложных - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 01:07 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 Dmitry Arefiev Это принципиально разные вещи. Основное принципиальное отличие в том, что вложенные транзакции в классическом понимании транзакций - вообще невозможны.Да, конечно. Я имел в виду практическую сторону вопроса, ибо некоторые производители называют сейвпойнты вложенными тр-циями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 01:39 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
hvlad SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ??? Это в Oracle :) Ну и наверное там где ЕСТЬ savepoint-ы Так что таки НЕТ это не одно и то-же ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 08:59 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) hvlad SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ??? Это в Oracle :) Ну и наверное там где ЕСТЬ savepoint-ы Так что таки НЕТ это не одно и то-же если в rollback указано, что откатываться надо до savepoint-а ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 09:03 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) GoldSquidВложенных транзакций не бывает! Код: plaintext 1. бывают Ну, а если почитать: 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. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 09:32 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохACID-ное durability требует, чтобы изменения, прибитые внутренним commit'ом были навсегда Это про транзакции. А ACID для вложенных транзакций где-то описывается ? Пьяный ЛохМожно модифицировать понятие durability, внеся туда понятие "области видимости". Тогда это становится savepoint'ом, который nested transaction. Пьяный ЛохВ простых случаях поведение и использование - идентично, в более сложных - нет. Да, вот и хотелось бы увидить хотя бы один случай, где они разные ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 09:43 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
pkarklin Gluk (Kazan) GoldSquidВложенных транзакций не бывает! Код: plaintext 1. бывают Ну, а если почитать: 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 вообще характерно называть вещи не своими именами (из самыхблагих маркетинговых соображений разумеется) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 09:46 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefiev Да, вот и хотелось бы увидить хотя бы один случай, где они разные ... В Oracle savepoint неявно ставится перед каждым DML-оператором, что позволяет откатить этот оператор при возникновении ошибки. Попробуйте сделять то-же с помощью "вложенных" транзакций. Кстати, в Oracle есть еще автономные транзакции, которые тоже не имеют никакого отношения к "вложенным" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 09:49 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Попробуйте сделять то-же с помощью "вложенных" транзакций. И в чем проблема ? Gluk (Kazan)Кстати, в Oracle есть еще автономные транзакции, которые тоже не имеют никакого отношения к "вложенным" Автономные транзакции скорее ближе к множественным транзакциям Interbase. Т.е. они скорее всего параллельные а не вложенные :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 09:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefiev Gluk (Kazan)Попробуйте сделять то-же с помощью "вложенных" транзакций. И в чем проблема ? В том чтобы откатить деятельность оператора, а не всю транзакцию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 10:08 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)В том чтобы откатить деятельность оператора, а не всю транзакцию Ну так откатывайте себе на здоровье, используя хоть вложенные транзакции, хоть точки сохранения. Только обрамляя каждый оператор блоком обработки исключительных ситуаций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 10:23 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Насколько я понимаю, разница между savepoint и nested transactions заключается в том, что вложенные транзакции позволяют образуют независимый собственный домен блокировок, в то время, как точки сохранения используют один общий домен - родительскую транзакцию. Кстати, существуют и такой подход, когда текстуально вложенная транзакция подтверждается независимо от статуса завершения объемлющей. На практике они используются практически в любой БД, применяющей UNDO/REDO протоколирование. В ARIES они называется nested top actions (NTA). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 10:25 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefiev Gluk (Kazan)В том чтобы откатить деятельность оператора, а не всю транзакцию Ну так откатывайте себе на здоровье, используя хоть вложенные транзакции, хоть точки сохранения. Только обрамляя каждый оператор блоком обработки исключительных ситуаций. В MS SQL rollback откатит всю транзакцию, а не только вложенную в этом и разница 2 teras Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахар ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 10:34 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Dmitry Arefiev Это про транзакции. А ACID для вложенных транзакций где-то описывается ? Нигде не описывается. Потому что не бывает ACID для вложенных транзакций. Конкретно - не бывает D. Бывает только "модифицированное D", т.е. для внешней транзакции закомиченные (внутренним комитом) изменения вполне дюрабильны, а для всего остального мира их еще не существует. Тогда это становится savepoint'ом, который nested transaction. Не становится. Да, вот и хотелось бы увидить хотя бы один случай, где они разные ... Напишите с использованием сейвпойнтов процедурину, которая обеспечивает атомарность, констистентность и изолированность (нужного уровня) для своих операций как при обычном вызове этой процедуры, так и при вызове внутри другой транзакции (в т.ч. с другим уровнем изоляции). И чтобы откат этой процедуры (в случае "вложенного" её вызова) не вызывал отката родительской транзакции, о которой вообще-то неизвестно ничего. Когда напишете - тогда приходите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:06 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Dmitry Arefiev З.Ы. Как было правильно сказано, сейвпоинты - это синтаксический сахар. Т.е. вроде как нельзя вложенные транзакции, но очччень хочеццо уметь "откатиться на чуть-чуть", причем сделать это более удобным способом, нежели выполнением обратных операторов. Всё, кроме как для "откатов на чуть-чуть" сейвпоинты больше ни для чего нужны быть не могут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:37 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 Dmitry Arefiev З.Ы. Как было правильно сказано, сейвпоинты - это синтаксический сахар. Т.е. вроде как нельзя вложенные транзакции, но очччень хочеццо уметь "откатиться на чуть-чуть", причем сделать это более удобным способом, нежели выполнением обратных операторов. Всё, кроме как для "откатов на чуть-чуть" сейвпоинты больше ни для чего нужны быть не могут. Не надо с больной головы на здоровую. Я говорил про вложенные транзакции. savepoint-ы сахар вполне себе семантический и на роль вложенных транзакций никогда не претендовавший. У него типа свои задачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:39 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Dmitry Arefiev Да, вот и хотелось бы увидить хотя бы один случай, где они разные ... В Oracle savepoint неявно ставится перед каждым DML-оператором, что позволяет откатить этот оператор при возникновении ошибки. Попробуйте сделять то-же с помощью "вложенных" транзакций.А в где они не ставятся ? :) С помощью "вложенных" это попробовать не получится, ибо их не бывает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:40 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) hvlad SergSupersave tran фиксирует текущее состояние и откатываться тогда будет до негоЭто в где ??? Это в Oracle :) Ну и наверное там где ЕСТЬ savepoint-ы Так что таки НЕТ это не одно и то-жеCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так. Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:42 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
hvladCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так. Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует) В Oracle savepoint-у НЕЛЬЗЯ делать commit, только rollback если было бы можно - тогда действительно был бы маразм ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:52 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) hvladCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так. Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует) В Oracle savepoint-у НЕЛЬЗЯ делать commit, только rollback если было бы можно - тогда действительно был бы маразмСлава Ларри, я в него верил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:09 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
hvlad Gluk (Kazan) hvladCommit savepoint'а это просто указание движку забыть об этом savepoint'е. Я сильно сомневаюсь, что в Оракле это не так. Впрочем ссылка меня может переубедить и сильно удивить (обычно у Оракла здравый смысл таки присутствует) В Oracle savepoint-у НЕЛЬЗЯ делать commit, только rollback если было бы можно - тогда действительно был бы маразмСлава Ларри, я в него верил :) дык ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:10 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохКогда напишете - тогда приходите. Т.е. проблема только в том, что точки отката унаследывают уровень изоляции, а вложенные транзакции позволяют его установить другим. Т.к. то, что будет происходить в W, будет обладать атомарностью, консистентностью и изолированностью той же как и внешняя транзакция по отношению к другим транзакциями, включая "содержащую" транзакцию. savepoint A; try ........ <<< W release savepoint A; except rollback to savepoint A; raise; end; PS: Я пытаюсь уловить не "важность" фразы "вложенная транзакция", а реальный смысл и реальные отличия от точек сохранения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:59 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievPS: Я пытаюсь уловить не "важность" фразы "вложенная транзакция", а реальный смысл и реальные отличия от точек сохранения. Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:08 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе Скажем так - с их рассмотрение я связался при обсуждении dbExpress 5 :) Мне указали, что вложенные транзакции нужно поддерживать и мол это совсем другое, нежели точки сохранения. Но можно долго пытаться увидеть в них модельную разницу. На практике - программисту доступны плоские транзакции и точки сохранения (автономные транзакции Oracle и синтаксис вложенных транзакций в MSSQL в расчет не беру). Последние могут быть вложенными. Остальное все - обсуждение какого цвета была бы шерсть у вуглускра, если бы он существовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:30 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
точки сохранения не могут быть вложенными, а вложенных транзакций (в том понимании в котором вы их ищите) действительно не существует (да и не нужны они) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:32 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievНа практике - программисту доступны плоские транзакции и точки сохранения (автономные транзакции Oracle и синтаксис вложенных транзакций в MSSQL в расчет не беру). Последние могут быть вложенными.Ещё раз - нет никаких вложенных транзакций в MSSQL. То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:39 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Gluk (Kazan) Не надо с больной головы на здоровую. Я говорил про вложенные транзакции. Вы, простите, говорили про какие вложенные транзакции? Про те, что MS называет вложенными? Так это не сахар, а самая обычная профанация, не имеющая никакого отношения ко вложенным транзакциям. ---------------------- 2 Dmitry Arefiev Т.е. проблема только в том, что точки отката унаследывают уровень изоляции, а вложенные транзакции позволяют его установить другим. Т.к. то, что будет происходить в W, будет обладать атомарностью, консистентностью и изолированностью той же как и внешняя транзакция по отношению к другим транзакциями, включая "содержащую" транзакцию. Проблема в том, что сейвпоинт невозможно закоммитить. Он не самодостаточен, в отличие от транзакции. А то, что MS называет вложенной транзакцией - невозможно откатить (не убив при этом все вышестоящее). Что называют вложенными транзакциями в dbExpress5 - я не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:51 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе Вообще-то "абстрактные вложенные транзакции не существующие в природе" - существуют. В MS Access, например :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:57 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
hvlad Dmitry ArefievНа практике - программисту доступны плоские транзакции и точки сохранения (автономные транзакции Oracle и синтаксис вложенных транзакций в MSSQL в расчет не беру). Последние могут быть вложенными.Ещё раз - нет никаких вложенных транзакций в MSSQL. То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint. Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:58 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan)Вы пытаетесь рассматривать какие-то абстрактные вложенные транзакции не существующие в природе Вообще-то "абстрактные вложенные транзакции не существующие в природе" - существуют. В MS Access, например :) Там вообще транзакций не существует. Ни вложенных ни плоских. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:59 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 Gluk (Kazan) Не надо с больной головы на здоровую. Я говорил про вложенные транзакции. Вы, простите, говорили про какие вложенные транзакции? Про те, что MS называет вложенными? Так это не сахар, а самая обычная профанация, не имеющая никакого отношения ко вложенным транзакциям. их родимых, от savepoint-ов хоть какая-то польза есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:00 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Там вообще транзакций не существует. Ни вложенных ни плоских. Дададад. Транзакции существуют только в оракле :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:01 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan)Там вообще транзакций не существует. Ни вложенных ни плоских. Дададад. Транзакции существуют только в оракле :) ну почему же ? И в MS SQL и в DB2 и в Postgress-е Это в акцесе недоразуменее какое-то (вы еще FoxPro вспомните, то-т фанаты порадюца) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:09 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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. Я не искал вложенные транзакции, я скорее всего искал их отсутствие :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:14 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)ну почему же ? И в MS SQL и в DB2 и в Postgress-е Бедный, бедный hvlad... Его тоже без транзакций оставили... Впрочем, если он попробует сказать, что они в FB есть, то тут же найдутся очередные фанаты, объевшиеся сырого мяса :) Это в акцесе недоразуменее какое-то (вы еще FoxPro вспомните, то-т фанаты порадюца) Фокс вспоминать не буду. Я его и не знал никогда. В общем, не будем отклоняться от темы. Если хотите - упорствуйте в своей глупости, не буду мешать. В аксесе от этого не станет меньше транзакций, в том числе и вложенных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:14 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Dmitry Arefiev В том смысле вложенные, что откат к A удалит и B и C. Для этого вообще не нужны B и C Я не искал вложенные транзакции, я скорее всего искал их отсутствие :) В MS SQL вложенных транзакций нет. Вы нашли отсутствие. Поздравляю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:16 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 Dmitry Arefiev В том смысле вложенные, что откат к A удалит и B и C. Для этого вообще не нужны B и C В том смысле, что при внешнем rollback поведение что сейвпоинтов, что вложенных транзакций, что псевдовложенных транзакций - идентично. Внутренности роли уже не играют. Различия есть только при внешнем commit и внутреннем rollback. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:26 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лохфанаты, объевшиеся сырого мяса :) Кстати, татарский бифштекс это немецкое блюдо. Во всяком случае мне так сказали. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:26 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохВ MS SQL вложенных транзакций нет. Вы нашли отсутствие. Поздравляю :) Спасибо. Надеюсь, что вложенных транзакций нет и в остальном реальном мире :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:27 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЕсли хотите - упорствуйте в своей глупости, не буду мешать. В аксесе от этого не станет меньше транзакций, в том числе и вложенных. но и больше их там не станет, обычный развод Лохов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:28 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievСпасибо. Надеюсь, что вложенных транзакций нет и в остальном реальном мире :) И не надейтесь :) Они есть в аксесе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:28 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) hvladЕщё раз - нет никаких вложенных транзакций в MSSQL. То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint. Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ???Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:37 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan)ну почему же ? И в MS SQL и в DB2 и в Postgress-е Бедный, бедный hvlad... Его тоже без транзакций оставили... Впрочем, если он попробует сказать, что они в FB есть, то тут же найдутся очередные фанаты, объевшиеся сырого мяса :) Это в акцесе недоразуменее какое-то (вы еще FoxPro вспомните, то-т фанаты порадюца) Фокс вспоминать не буду. Я его и не знал никогда. В общем, не будем отклоняться от темы. Если хотите - упорствуйте в своей глупости, не буду мешать. В аксесе от этого не станет меньше транзакций, в том числе и вложенных. Я в курсе ваше заблуждения относительно наличия транзакций в акцесе, поэтому не буду спрашивать как там обеспечивается ACID ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:41 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:42 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
hvlad Gluk (Kazan) hvladЕщё раз - нет никаких вложенных транзакций в MSSQL. То, что там названо nested transactions, на самом деле ничем не отличается от обычных savepoint. Не имеют они ДАЖЕ с savepoint-ами НИЧЕГО общего, ибо не сайвают и не пойнтят ничего а только увеличивают счетчик вложенности, который commit-ы уменьшают. Как до нуля доходит фиксируется. Какие это нафик savepoint-ы ???Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты. угу, до начала основной транзакции, если склероз мне не изменяет впрочем, если вы порадуете меня опровергающей ссылкой из BOL, признаю свою неправоту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:43 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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) Я тоже в курсе Ваших заблуждений, так что продолжайте упорствовать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:45 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохРусским по белому же сказано: [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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 15:06 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)2 teras Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахарПожалуй, я неудачно выразился. Имеется в виду владелец блокировок. Каждая транзакция удерживает набор блокировок. В случае с savepoint - все блокировки получаются от имени одной транзакции. В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой. Насчет MS SQL не знаю - не пользую. Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 15:52 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras Gluk (Kazan)2 teras Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахарПожалуй, я неудачно выразился. Имеется в виду владелец блокировок. Каждая транзакция удерживает набор блокировок. В случае с savepoint - все блокировки получаются от имени одной транзакции. В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой. Насчет MS SQL не знаю - не пользую. Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах. Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 15:59 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 teras В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Это зачем? Для всего остального мира эти две транзакции неотличимы (собственно, они обязаны выглядеть как одна, внешняя), а внутри - родительской транзакции нет смысла конкурировать с дочерней, равно как и наоборот, ибо ни к чему хорошему такая конкуренция не приведет, за исключением возможности дэдлока транзакции со своими собственными внутренностями. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой. А это вообще как? Если две транзакции вложены в третью, но не вложены друг в друга - то они исполняются последовательно. К тому моменту, как начинается вторая - первая уже завершена, и какие-либо специфические блокировки (отличные от "родительских") все сняты, даже если они были. Как транзакции могут между собой конкурировать, если они по времени не пересекаются? Насчет MS SQL не знаю - не пользую. А что пользуете? Т.е. присоединяюсь к вопросу - это абстрактные рассуждения или нет? Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах. Совсем гениально. Вложенные begin trans/commit trans - позволяют не заботиться о расстановке begin trans/commit trans? Хлопаю одной ладонью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 16:49 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefiev пишет: > сохранения (savepoint) это: > 1) одно и то же, но названное по разному; > 2) или существуют принципиальные факты различий в их поведении. Почти одно и тоже. Разница только в том, что во вложенных транзакциях нельзя откатить транзакцию частично, а при наличии savepoint - можно. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 16:50 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
hvlad пишет: > Транзакция или вся выполняется, или вся не выполняется. Всё остальное - > не транзакция Это классическая ACID-транзакция. Мы вроде бы говорим о двух ее расширениях. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 16:53 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras пишет: > заключается в том, что вложенные транзакции позволяют образуют > независимый собственный домен блокировок, в то время, как точки В определении моделей транзакций про блокировки ничего нет, потому как это уже реализация, а не модель. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 16:56 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
MasterZivРазница только в том, что во вложенных транзакциях нельзя откатить транзакцию частично Давайте называть кошку кошкой. Транзакцию вообще нельзя откатить частично. Если какие-то изменения были - то они были все. Вложенные транзакции (в нормальном, а не майкрософтовском понимании этого слова) затем и нужны, чтобы оформленной во вложенную транзакцию единицы работы - не было (при откате). То, что эту функциональность урезали и обозвали словом "сейвпоинт", а вложенной транзакцией обозвали какую-то белиберду, которую даже откатить нельзя - это п....ц какая заслуга майкрософта. Но не стоит за ними эту фигню повторять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:03 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
MasterZivво вложенных транзакциях нельзя откатить транзакцию частично, а при наличии savepoint - можно Игра слов. И в том и в другом случае - можно откатить конкретный кусок изменений. Если использовать несуществующие-в-природе вложенные транзакции, то они позволяют откатить кусок изменений корневой транзакции, равный объему изменений вложенной транзакции. Т.е. с точки зрения корневой транзакции - точка сохранения и вложенная транзакция одна хрень, когда идет разговор об откате изменений. Играя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ... Но их нет в природе ... А потому апельсин может быть соленым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:11 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Если использовать несуществующие-в-природе вложенные транзакции Я категорически протестую против использования слов "несуществующие в природе" :) Существующие, еще как существующие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:16 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievИграя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ... Я уже назвал еще одно отличие. Вложенная транзакция - она в первую очередь транзакция, а уж потом вложенная. Т.к. она транзакция - она может быть использована как самостоятельная единица. Сама, **я, без ансамбля. Завернули транзакцию в процедуру, вызвали её - получили нормальную, вполне обычную транзакцию. Вызвали эту же процедуру внутри другой транзакции - нормальная транзакция превратилась во вложенную. А вот сейвпоинт - сам по себе использован быть не может. Он "чисто внутренний". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:20 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Dmitry ArefievИграя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ... Я уже назвал еще одно отличие. Вложенная транзакция - она в первую очередь транзакция, а уж потом вложенная. Т.к. она транзакция - она может быть использована как самостоятельная единица. Сама, **я, без ансамбля. Завернули транзакцию в процедуру, вызвали её - получили нормальную, вполне обычную транзакцию. Вызвали эту же процедуру внутри другой транзакции - нормальная транзакция превратилась во вложенную. А вот сейвпоинт - сам по себе использован быть не может. Он "чисто внутренний". То чего хотите есть у нас. Только называется по другому - автономная транзакция. Удобный способ получения deadlock-а в рамках одной сессии P.S. До завтра ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:25 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция. Это разные вещи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:28 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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. поведет себя не совсем так, как я ожидал бы от вложенных транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:39 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЭто разные вещи. Совершенно разные. А то, что вы мне предлагаете попробовать сделать при помощи "самостоятельной единицы" транзакции, так это уже не вложенная транзакция ... Дискусии - большое спасибо, все прояснил для себя ! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 17:40 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievА то, что вы мне предлагаете попробовать сделать при помощи "самостоятельной единицы" транзакции, так это уже не вложенная транзакция ... Вы про что? Что именно я предлагаю попробовать сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 18:21 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
softwarerпоскольку синтаксис у них заведомо другой. Это, с моей точки зрения, есть основное отличие. Ну я думаю, семантическим и дополнительным практическим отличием вложенных транзакций от точек сохранения может быть то, что вложенные транзакции могут усилить уровень изоляции. В остальном, хоть убейте, но логической разницы не вижу. Лишь - разные термины, разный синтаксис ... Вам как дельфийцу, может быть интересна отправная точка обсуждения :) Два варианта: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. и другой ... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Второй вариант предполагает наличие самостоятельных, вложенных транзакций. И тут возникает элементарная ситуация. Вот код в точке B берет и делает oTX.Commit/Rollback - т.е. завершает корневую транзакцию. Тогда все oTXi становятся инвалидными. И обращение к ним ведет к exception, а без них логика в полный рост не работает ... Собственно я за схему (1). Коли имеется природа стека, то пусть такой и объектная модель и поведение будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 19:46 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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. Как видите, тут как бы это выразиться, не совсем стек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 20:27 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 softwarer Вызвано это, насколько я понимаю, сугубо прикладными причинами (желанием прочитать в dirty read нечто, оставив остальной транзакции возможность работать в нормальном режиме) А почему Вы не рассмотрели обратную ситуацию - когда хочется "вложенную" часть выполнить на более высоком уровне изоляции? Тогда и "нонсенс внутри" не совсем нонсенс, и озвученная проблема "на каком уровне изоляции ХП может исполняться" не совсем проблема - ХП просто себе выставит нужный ей уровень, отработает, и преспокойно закоммитится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 20:41 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 по необходимости). Не хочу обсуждать, насколько такой подход был оправданным (по меньшей мере он был систематичным), но при наличии такого счетчика, можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 20:53 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохА почему Вы не рассмотрели обратную ситуацию - когда хочется "вложенную" часть выполнить на более высоком уровне изоляции? Еще раз. Для меня нонсенс - вообще желание менять уровни внутри одной транзакции, независимо от того, в какую сторону. Это приводит к идеологическому бардаку в и так не самой прозрачной картине многопользовательской работы. В частности, написанный Вами вариант означает среди прочего следующее: в одной и той же транзакции мы сначала читаем новые данные, потом повышаем уровень, делаем тот же селект - и читаем более старую версию тех же данных. Парадокс, однако. Пьяный Лохи озвученная проблема "на каком уровне изоляции ХП может исполняться" не совсем проблема - ХП просто себе выставит нужный ей уровень, отработает, и преспокойно закоммитится. Насколько я понимаю, вложенные транзакции в MSSQL в значительной степени аргументируются именно этой возможностью. Однако, это всего лишь заметание мусора под кровать. Вместо "бардака внутри ХП" будет "бардак в вызывающем коде", разницы не особо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 21:07 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
softwarer Я тут погуляв с собакой, увидел проблемы и в своих и в ваших рассуждениях. Короче, буду думать - что-то все не слишком однозначно с API. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 21:33 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievКороче, буду думать - что-то все не слишком однозначно с API. Я бы предложил еще и обсудить в форуме дельфы или возможно в личной переписке с избранными :) Это действительно непростой вопрос, подойти к которому стоит очень аккуратно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 21:56 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую. Это как это? Как может родительская транзакция смотреть на вложенную в неё? Т.е. мы имеем такую последовательность - Родительская транзакция - Некие действия 1 - - Вложенная транзакция - - Некие действия 2 - - Конец вложенной транзакции - Некие действия 3 - Конец родительской транзакции В каком месте тут родительская транзакция может смотреть на вложенную? Может Вы путаете с автономными транзакциями? terasОчень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении. Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 23:51 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
softwarer пишет: > Вот это как раз очень спорный момент. Насколько я знаю, в некоторых > серверах существует возможность менять уровень изоляции внутри > транзации, но с моей точки зрения это - нонсенс. Вызвано это, насколько Это только кажется, что нонсенс. На самом деле в некоторых СУБД уровень изоляции можно менять даже для отдельной таблицы конкретного запроса . И в общем-то оно понятно, поскольку уровень изоляции в конце концов лишь сила блокировок, накладываемых на обрабатываемые данные. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 00:06 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
softwarer пишет: > Насколько я понимаю, вложенные транзакции в MSSQL в значительной степени > аргументируются именно этой возможностью. В смысле, чтобы дать выполнится процедуре на любом нужном ей уровне транзакций ? Тогда нет, вложенные транзакции могут и без процедур использоваться. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 00:09 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто только кажется, что нонсенс. MasterZivНа самом деле в некоторых СУБД уровень изоляции можно менять даже для отдельной таблицы конкретного запроса . Да. Я не стал об этом упоминать, дабы меня не заподозрили в желании поднять флейм о конкретных некоторых СУБД, но это безусловно пик бессмысленности. Можно помедитировать, например, над смыслом запроса, который дважды обращается к одной таблице с разными уровнями изоляции при этом. Впрочем, это бред в любом случае, поскольку означает запрос на получение заведомо рассинхронизованных данных. MasterZivИ в общем-то оно понятно, поскольку уровень изоляции в конце концов лишь сила блокировок, накладываемых на обрабатываемые данные. :) Чтобы оценить смысл какого-то действия, нужно отвлечься от физики его реализации. Например, "в конце концов любые данные есть последовательность битов", но из этого никак не следует осмысленность присваивания переменной "остаток средств на счету" значения "устав караульной службы Российской армии". Так и здесь: из того, что нечто можно сделать (в частности, выполнить такой бардачный запрос) совершенно не следует, что это нужно делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 01:18 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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, что-то сделали, закоммитились... Эта последовательность действий - нонсенс (для Вас), или нет? Если нет, то почему та же самая последовательность действий превращается в нонсенс как только её оборачиваем в транзакцию? Если да, то выходит, что по хорошему надо вообще запретить менять уровень изоляции. Как один какой-то уровень изоляции выставили, так с ним и работают. Причем все. Выставили всем сериалайзбл, и все довольны :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 07:43 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
По поводу того, что родительская транзакция в принципе не может смотреть на незакомиченные изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на незакомиченные изменения родительской. так корректнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 07:46 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция. Это разные вещи. почему ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 08:30 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция. Это разные вещи. почему ? По поведению. Rollback внешней транзакции не откатит автономную, если я правильно понимаю. В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 08:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras Gluk (Kazan)Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?И то и другое. Собственно, вопрос ведь вначале прозвучал абстрактно, так и отвечал. Сама модель - следствие чтения описаний алгоритмов, таких, как ARIES/NT и т.п. Что касается практики, то такой подход точно реализован в BDB, и, кроме, того встречался в документации на другие продукты. вот тут не нашел каких-то феноменальных отличий от автономных транзакций teras MasterZivВ определении моделей транзакций про блокировки ничего нет, потому как это уже реализация, а не модель. Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую. Блокировки это один из механизмов обеспечения изоляции транзакций. Для версионников это особенно очевидно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 09:23 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan) Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция. Это разные вещи. почему ? По поведению. Rollback внешней транзакции не откатит автономную, если я правильно понимаю. В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию. Нет, родительская транзакция ждет завершения автономной и откатить ее не может по оппределению. Какие то тонкие различия могут быть в изоляции между родительской и вложенной, но по описанию BDB пока не уловил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 09:37 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Для версионников это особенно очевидно :) Вот только само существование версионников не для всех очевидно. Что особенно неприятно, комитет по стандартам тоже в их числе. Отсюда в их стандарте определение уровней изоляции через блокировки и феномены. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 09:37 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan) Пьяный Лох Gluk (Kazan)То чего хотите есть у нас. Только называется по другому - автономная транзакция. Это разные вещи. почему ? По поведению. Rollback внешней транзакции не откатит автономную, если я правильно понимаю. В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию. Sorry, теперь включился На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 09:39 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Gluk (Kazan)Для версионников это особенно очевидно :) Вот только само существование версионников не для всех очевидно. Что особенно неприятно, комитет по стандартам тоже в их числе. Отсюда в их стандарте определение уровней изоляции через блокировки и феномены. Posted via ActualForum NNTP Server 1.4 Этим старым перичникам вообще мало что очевидно :( Но Microsoft к примеры уже проголосовал за версионность, так что процесс идет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 09:41 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Sorry, теперь включился На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме. Пардон, в чём каша то? Код: plaintext 1. 2. Имхо - абсолютно логичное поведение было бы, если бы оно было таким. Почему такая конструкция не должна откатить что-то внутри - не понимаю. Почему такая конструкция должна откатывать что-то снаружи - не понимаю тем более. Если очень хочется внутри транзакции иметь нечто особенного, представляющее из себя неоткатываемый, независимый кусок - ну как бы можно конечно, но при явно выраженном и синтаксически оформленном желании. Назовите это явно выраженное и синтаксически оформленное желание хоть "маленькой зелёненькой пирамидкой", хоть "автономной транзакцией" - нет вопросов. Но смешивать в одну кучу со вложенными транзакциями не следует. Хотя ИМХО было бы более правильно оформлять эту "маленькую зелёненькую пирамидку" именно как отдельную самую обычную транзакцию, просто со необычным уровнем изоляции - "изолирована от всего, за исключением одной отдельно взятой рядом исполняющейся транзакции". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 09:59 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 10:26 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Gluk (Kazan) то что "маленькие зеленые пирамидки" нужны вопросов не вызывает Не вызывает. То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. То, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает. Я как бы ни с чем и не спорю. Просто если "маленькая зелёненькая пирамидка" по факту является независимой транзакцией со специфичным уровнем изоляции - то я бы предпочёл называть её именно независимой транзакцией со специфичным уровнем изоляции. Если её называют по другому - ничего страшного, главное не запутаться. Если она по факту является чем-то другим - ну значит мои рассуждения на тему "как бы это покрасивше назвать" можно выкинуть в помойку, я не обижусь. Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна Необходимость "частичного" отката для Вас вопросов не вызывает? Надеюсь, что нет. Если да, то можно порассуждать на тему "зачем нужны сейвпоинты", но лучше не будем. Необходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны. Если объединить "частичный" откат с "условным" коммитом - получится вполне съедобная вложенная транзакция. Но у MS (в MS SQL Server) половина функционала (а именно условный коммит) - оставлена на Commit'е, а вторая половина (а именно частичный ролбек) - перекочевала в сейвпойнты. В итоге получилась полная херня. Самое непонятное, что эти же люди сделали Access, где "условный" Commit вполне нормально сосуществует с "частичным" Rollback. (предлагаю воздержаться от оффтопа на тему Вашего неверия в существование транзакций в аксесе ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 10:41 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. Вот это вызывает вопросы. И в Oracle этого нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 10:49 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Пьяный Лох То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. Вот это вызывает вопросы. И в Oracle этого нет Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 10:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохНеобходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны. Вызывает. Очень сильно вызывает :( В Oracle 10g тоже наплодили всяких commit-ов которые не совсем commit-ы или совсем commit-ы, но только по субботам Лично меня это сильно печалит. commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 10:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Gluk (Kazan) Пьяный Лох То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. Вот это вызывает вопросы. И в Oracle этого нет Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :) не то процитировал :( Пьяный ЛохТо, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает. вот это ВЫЗЫВАЕТ вопросы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 10:55 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Gluk (Kazan) Пьяный ЛохНеобходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны. Вызывает. Очень сильно вызывает :( А почему? Вам так сильно хочется писать код в стиле упомянутого на прошлой странице, т.е. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Мне лично такое вовсе не нужно. Писать больше, думать потом еще, где какую вызвать... Ну его в пень. Программист - животное ленивое. Я вполне буду доволен, если смогу один раз написать Код: plaintext 1. 2. 3. 4. 5. 6. 7. Собственно, в MS SQL Server я именно так и могу сделать. Я не могу безбоязненно в эту процедурину Rollback запихнуть :) не то процитировал :( Пьяный ЛохТо, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает. вот это ВЫЗЫВАЕТ вопросы Но ведь автономная транзакция имеет доступ к измененным, но, разумеется, еще незакомеченным данным "родительской"? Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:05 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу ну а допустим надо какое-то действие откатить, но записать об этом в лог для лога должен быть commit, для основного действия rollback мне например не нравится что в MS SQL такое не сделать стандартными средствами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:05 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
SergSuper Gluk (Kazan)commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу ну а допустим надо какое-то действие откатить, но записать об этом в лог для лога должен быть commit, для основного действия rollback Для того и были созданы автономные транзакции. Но автономная транзакция - независима от основной и полностью изолирована. Это просто способ выполнить какие-то транзакционные действия ЗА ПРЕДЕЛАМИ основной транзакции ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:11 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
softwarer пишет: > Впрочем, это бред в любом случае, поскольку означает запрос на получение > заведомо рассинхронизованных данных. Это не бред. Ты просто воинствующий идеалист. Транзакция - это абстракция, и ее нельзя ограничивать какими-то соображениями, кроме базовых свойств, потому что нельзя предсказать логику конкретного приложения - она может быть любой. Любая возможность может быть востребована приложением. Тебя напр. не смущает, что управляя транзакцией вручную (multi-statement) можно даже целостность транзакции нарушать ? Ну и что, целостность - тоже абстракция, она с точки зрения конкретного приложения может быть совершенно другой. > :) Чтобы оценить смысл какого-то действия, нужно отвлечься от физики его > реализации. Например, "в конце концов любые данные есть Получишь скорость сферического коня в вакууме. Оно интересно, но только с чисто теоретической стороны. > Так и здесь: из того, что нечто можно сделать (в частности, выполнить > такой бардачный запрос) совершенно не следует, что это нужно делать. Тебе не нужно. Но ты - не все приложения на свете. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:12 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
SergSuperмне например не нравится что в MS SQL такое не сделать стандартными средствами Это можно и стандартными средствами, если вспомнить, что табличные переменные не подвержены действию откатов транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:15 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
MasterZiv Тебя напр. не смущает, что управляя транзакцией вручную (multi-statement) можно даже целостность транзакции нарушать ? Ну и что, целостность - тоже абстракция, она с точки зрения конкретного приложения может быть совершенно другой. Целостность не нарушается ни на уровне операторов ни на уровне транзакции. Пока мы выполняем какие-то действия в транзакции, все наши действия - часть транзакции. Мы не можем нарушить ее целостность, мы можем только выполнить другую транзакцию. Сервер не обязан знать какой смысл вкладывает в выполняемые действия приложения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:27 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Код: plaintext 1. 2. 3. 4. 5. 6. 7. Голова большой, но металлический :( Логика вложенности процедур ой как далеко не всегда связана с логикой подтверждения транзакций. Так что разработчику включать голову ПОЛЕЗНО полюбому ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:32 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
SergSuper teras вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую. Это как это? Как может родительская транзакция смотреть на вложенную в неё? Т.е. мы имеем такую последовательность - Родительская транзакция - Некие действия 1 - - Вложенная транзакция - - Некие действия 2 - - Конец вложенной транзакции - Некие действия 3 - Конец родительской транзакции То, что здесь написано - никоим образом не противоречит тому, что сказал я. Зато уже вполне в состоянии улучшить конкурентность, за счет освобождения разделяемых ресурсов, занятых вложенной транзакцией. В общем случае возможна ситуация, когда один поток работает с несколькими транзакциями попеременно. Например: - Родительская транзакция (P) -- Запуск вложенной транзакции (T1) -- Запуск вложенной транзакции (T2) -- Действие в транзакции (T1) -- Действие в транзакции (T2) -- Действие в транзакции (T1) -- Конец вложенной транзакции (T2) -- Действие в транзакции (T1) -- Конец вложенной транзакции (T1) - Конец родительской транзакции(P) SergSuperМожет Вы путаете с автономными транзакциями? Автономные транзакции - это те, что появились в Oracle (pragma autonomous_transaction)? Это несколько не то. Судя по тому, что про них пишут это NTA, про которые я уже писал. terasОчень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении. Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией[/quot] Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 20:24 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна Запись в логи - чтобы при откате транзакции не стирались ее следы из лога. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 21:02 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЭто, простите, какая-то чушь. Вы, похоже, непонимаете, что изоляция - это защита (требуемого уровня) исполняемой транзакции от изменений во внешнем мире, а вовсе не защита внешнего мира от изменений в транзакции. Чушь, только потому, что не согласуется с вашими понятиями? Любопытно, одному не нравится упоминание блокировок, другому - простое описание (без учета 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, по ситуации), вызывай её откуда хочешь, и никакого геморроя со счетчиками невнятными. Вот-вот, именно про это я и написал. В таком подходе можно не заботиться о расстановке коммитов - существует единая и очень простая схема. Как там? "Хлопаете одной ладонью"? ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 21:29 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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." Здесь родительская транзакция не упоминается потому, что он не может обращаться к базе, пока существует хотя бы одна дочерняя. Могу предположить, что это связано либо с нежеланием разбираться с передачей прав на блокировки от родителя потомку в динамике, либо с нежеланием отслеживать действительное состояние транзакции для разборок с взаимоблокировками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2007, 00:10 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras SergSuper Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией? По определению. Если уж википедия для Вас авторитет, то извольте: Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными. И соответственно все остальные Ваши рассуждения тогда ничего не стоят. Ну сами подумайте: один поток делает А=1, другой паралельно делает А=2. В итоге результат работы оказывается непредсказуем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2007, 12:52 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
SergSuper Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными. Что-же, этого вполне достаточно для ответа. Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются. Возникает вопрос - что тогда последовательные операции? Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая . Думаю, с этим трудно не согласиться. Как и с тем, что это определение никоим образом не противоречит понятию потоков. Собственно, единственное, что нужно сделать на практике, чтобы добиться последовательности исполнения операций разных потоков в одной транзакции, в соответствии с этим определением - например, использовать что-то наподобие мютекса, выделенного на транзакцию или гарантировать последовательность алгоритмически. Кстати, опять же, это не только теория. Та же пресловутая BDB, насколько я помню, именно так работает с транзакциями. При этом она еще и возлагают требование соблюдения последовательности на программиста. SergSuperНу сами подумайте: один поток делает А=1, другой паралельно делает А=2. В итоге результат работы оказывается непредсказуем Подумал. Здесь вы, говорите не о последовательных операциях, а, скорее, об упорядочивании операций или о непротиворечивости данных. Это всегда было и будет заботой программиста. Вы же не станете требовать предсказуемости значения операции A=random() mod 2 + 1? А это - аналог вашей модели. SergSuperИ соответственно все остальные Ваши рассуждения тогда ничего не стоят. Знаете, у меня тоже нет особого желания доказывать . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2007, 21:09 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая . Думаю, с этим трудно не согласиться. Как и с тем, что это определение никоим образом не противоречит понятию потоков. Собственно, единственное, что нужно сделать на практике, чтобы добиться последовательности исполнения операций разных потоков в одной транзакции, в соответствии с этим определением - например, использовать что-то наподобие мютекса, выделенного на транзакцию или гарантировать последовательность алгоритмически. Кстати, опять же, это не только теория. Та же пресловутая BDB, насколько я помню, именно так работает с транзакциями. При этом она еще и возлагают требование соблюдения последовательности на программиста. "После сборки тщательно обработать напильником" Если нужно еще и что-то делать на практике - то, извините, противоречит. Т.е. то что Вы сделаете при соблюдении требования последовательности (кстати а где гарантия что не сделаете ошибки?) еще можно назвать транзакцией, но такую конструкцию, предоставляемую СУБД (не знаю как это правильно назвать) - нет. Да и как-то странно будёт всё это выгдядеть - делать кучу потоков и запускать каждый только после того как закончится предыдущий. Ну это так, лирическое отступление. Про random и непротиворечивость - на самом деле можно много спорить, но я думаю не стоит. Будем считать я этого не писал, тоже типа было лирическое отступление ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2007, 00:07 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
SergSuperЕсли нужно еще и что-то делать на практике - то, извините, противоречит. Т.е. то что Вы сделаете при соблюдении требования последовательности (кстати а где гарантия что не сделаете ошибки?) еще можно назвать транзакцией, но такую конструкцию, предоставляемую СУБД (не знаю как это правильно назвать) - нет. С точки зрения СУБД, последовательность операций - необходимое и достаточное требование для транзакции. Но вы правы, так, как подобные возможности нужны очень редко, вводятся дальнейшие ограничения чтобы сократить количество ошибок программиста. Кроме того, если они действительно требуются (а такое тоже бывает), можно реализовать достаточно неплохую аппроксимацию и в самой программе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2007, 01:18 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 08:20 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Выбегалло Gluk (Kazan)то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна Запись в логи - чтобы при откате транзакции не стирались ее следы из лога. см. "маленькие зеленые пирамидки" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 09:35 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох teras SergSuper Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными. Что-же, этого вполне достаточно для ответа. Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются. Возникает вопрос - что тогда последовательные операции? Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая Что-то Вы совсем в определениях запутались. Как это "не идет речи о синхронности/асинхронности"? Именно об этом речь и идёт. Операции либо выполняются последовательно, т.е. неодновременно, т.е. асинхронно, либо выполняются параллельно, т.е. одновременно, т.е. синхронно. teras таки не прав, но не по той причине, что вы назвали. Вы зря равняете неодновременность с асинхронностью, а параллельность с одновременностью. Это не так, но не будем в это вдаваться. Чтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам. teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 17:16 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 mir Вы зря равняете неодновременность с асинхронностью Чего??? Эти слова - одно и то же. Просто одно слово - русское, а другое - греческое. Чтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам Неверно. Понятия синхронности/асинхронности (по-русски - одновременности/неодновременности) применимы к любым процессам. Последовательные операции, понятное дело, всегда и абсолютно асинхронны. teras не прав Да я ж не спорю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2007, 18:14 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
mirЧтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам. teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы. Вот. Об этом я и твержу - потоки, синхронность/асинхронность - это понятия из области теории операционных систем, а транзакция, последовательность операции и пр. - это из области теории баз данных. И это - принципиально разные вещи. Настолько разные, что ни одна более/менее серьезная книга по БД не проводит таких параллелей. Да вы сами попробуйте реализовать что-то подобное базе данных с транзакциями, скажем - на основании массива, с построчными блокировками, транзакции представлены в виде отдельных объектов, и вы легко поймете, что эквивалентность потока и транзакции - это только удобство, но никак не необходимость - последовательного исполнения операций вполне достаточно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 01:23 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Если я не хочу слышать, что Вы мне говорите , то я могу заткнуть себе уши. А могу отрезать Вам язык. Требуемый результат достигнут, хоть и разными способами. Да, это заметно. Пьяный ЛохВы попытались привязать понятие изоляции к тому, видимы ли незакомиченные изменения другим транзакциям? Это - чушь. Изоляция - она совсем про другое. Она определяет "видимость" в совсем другую сторону, и с совсем другими (более многообразными) критериями, согласно которым изменения видны либо не видны. Не надо смешивать понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) и уровня изоляции (декларирование условий, при которых для данной транзакции свойство изоляции будет выполнено). Изоляция определяется взаимодействем транзакций, в частности - незакоммиченными операциями. Вы все время говорите про понятие уровня изоляции. Пьяный ЛохПочему ж необсуждаемо? Очень даже обсуждаемоSQL не определяет уровней изоляции DIRTY READ и SNAPSHOT. А версионность - это один из способов достичь уровня SERIALIZABLE. Пьяный ЛохИменно при том. Это же Вы начали разговор про какие-то блокировки между внешней и внутренней транзакцией? Вот я и говорю Вам, что эти блокировки в принципе не могут быть нужны, ибо единственное к чему они могут привести - deadlock на ровном месте. Возможность возникновения взаимоблокировок - это свойство системы, применяющей блокировки для обеспечения работы планировщика БД. Написать приложение без взаимоблокировок - задача программиста. Причем здесь deadlock? Пьяный Лох Посмотрите тогда на BDB. Благодарю. Вы написали достаточно, чтобы у меня не возникло ни малейшего желание смотреть на систему, где транзакциями называют что-то совсем на транзакции непохожее. Что сказать? Если вас пугают возможности - действительно, не стоит использовать инструмент в принципе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 01:48 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛП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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 06:52 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 teras понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) О! Вторая попытка :) Сравните её с первой Вашей попыткой: "свойство изоляции ... - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую." Не надо смешивать понятия изоляции ... и уровня изоляции Так я и не смешиваю. Это Вы смешиваете. В первый раз за понятие изоляции Вы зачем-то выдали описание уровня изоляции Read Committed (да еще и неправильное). Во второй раз за понятие изоляции Вы зачем-то выдали описание уровня изоляции Serializable Вы все время говорите про понятие уровня изоляции. Этой напасти подвержены именно Вы, увы :) SQL не определяет уровней изоляции DIRTY READ и SNAPSHOT. У Вас плохой SQL. У меня - прекрасно определяет :) Уж не буду Вас поправлять по поводу того, что SQL - это язык, он не определяет, это его определяют. А версионность - это один из способов достичь уровня SERIALIZABLE. Отнюдь. Версионность - один из способов НЕ достичь уровня Serializable. Причем здесь deadlock? Для тупых еще раз. Deadlock при том, что возможность его появления - единственное , что можно получить от упомянутых Вами бредовых блокировок между родительской и дочерней транзацией. В пятый раз повторять не буду, уж извините. Что сказать? Если вас пугают возможности Да нет, что Вы. Они меня смешат :) --------------------------- 2 mir Во-первых, ваш перевод с греческого неточен: Во-первых, если уж Вы беретесь обсуждать тонкости перевода с русского на греческий и обратно, то не стоит использовать в качестве аргументов толковые словари для китайского языка, японского языка, немецкого языка, и для английского языка - тоже не стоит. То есть смысл по гречески: «не привязанный ко времени», «не скоординированный во времени», а вовсе не «неодновременный». Греческий смысл греческого слова Вы умудрились вычитать в толковом английском словаре? Браво Как видим, нам нужно компьютерное, то есть 4-е значение. Нет, не видим. Ну не видим мы data transmition link и прочих different speed. Поэтому 4-ое значение - нам не нужно, хоть Вы его и считаете более компьютерным :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 08:22 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 teras авторНе надо смешивать понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) и уровня изоляции (декларирование условий, при которых для данной транзакции свойство изоляции будет выполнено). А вторая часть Вашего высказывания - еще более весёлая, чем первая. Декларирование условий, значит? Вы хотите сказать, что как только я ставлю уровень изоляции Read Committed, так тут же я этим уровнем изоляции декларирую, что если транзакция не будет видеть чужие незакомиченные изменения, то св-во изоляции будет выполнено, т.е. система обрет св-во "прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно"? Декларация Read Committed как способ достижения всеобщего Serializable. Браво ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 08:35 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохВо-первых, если уж Вы беретесь обсуждать тонкости перевода с русского на греческий и обратно, то не стоит использовать в качестве аргументов толковые словари для китайского языка, японского языка, немецкого языка, и для английского языка - тоже не стоит. А вы-то почему беретесь обсуждать тонкости перевода с русского на греческий и обратно? Вашу речь оправдало бы одно: если бы вы привели обоснование своего перевода. Поэтому не стоит критиковать другого за иностранные источники, коли у вас нет ни иностранных, ни русских, никаких. Пьяный Лох То есть смысл по гречески: «не привязанный ко времени», «не скоординированный во времени», а вовсе не «неодновременный». Греческий смысл греческого слова Вы умудрились вычитать в толковом английском словаре? Браво В толковом английском словаре я вычитал английский смысл греческого слова. Не нравится мой перевод для "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 взаимодействие есть, и оно асинхронное. Однако к реальной одновременности это взаимодействие не имеет отношения. Я могу заправляться в другое время, чем когда приезжает заправщик, а могу одновременно (забудем пока про технику безопасности, тут дело в принципе). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 10:47 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЛадно, надоело. Объяснять свою точку зрения можно только тогда, когда собеседник хочет услышать. У вас же пока видно только стремление принизить собеседника, используя сарказм и личные нападки, видимо вы считаете, что вас это возвышает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 11:31 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 Ладно, надоело. Жалко. Я надеялся, что Вы еще порадуете нас мудрыми определениями :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 12:09 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛП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 - увеличение количества бензина в Вашем бензобаке. Идёт? Нет. Здесь нет ничего лишнего. Без заправки (то есть буфера) асинхронное взаимодействие невозможно. Мне придется ждать, пока приедет заправщик, заправщику придется ждать, пока приеду я. А это совсем не то же самое. Поэтому дальнейшие ваши рассуждения несколько некорректны. Буфер не деталь реализации, а необходимое условие асинхронного взаимодействия. Могу другой пример: если почтальон носит вам почту, пользуясь почтовым ящиком (он кидает, вы берёте), это асинхронное взаимодействие. Если он должен вручать вам почту лично в руки (как телеграммы), это синхронное. Это два принципиально разных подхода. Но асинхронность не означает обязательного требования неодновременности. Оно означает отсутствие зависимости от одновременности, необязательность одновременности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 17:52 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 mir То есть «асинхронный» значит не «противоположный одновременности» (это было бы antisynchronos), а скорее «не обладающий свойством одновременности» или «не требующий одновременности». Возражение принято. Русское же «неодновременный» гораздо категоричнее. Возможно, более корректно было бы использовать частицу "не" вместо приставки. Т.е. не "неодновременный", а "не одновременный". А вы от каких аномалий умудрились не увидеть разговор про потоки? Разговор про потоки я вполне увидел. Но в потоках я по прежнему не вижу "data transmition link between different computers" :) И от каких аномалий вы упёрлись в эти telecommunication signaling, не заметив в первом же определении просто «objects or events»? От аномалий "грязного чтения", вестимо :) Нет. Здесь нет ничего лишнего. Без заправки (то есть буфера) асинхронное взаимодействие невозможно. Взаимодействие - невозможно. А асинхронное выполнение процессов - вполне. Бензовоз, например, вполне может опорожняться прямо на землю, и процесс этот по времени будет совершенно независим от (т.е. "не одновременен с", "необязательно одновременен с") уже несвязанным процессом пополнения бака Вашего автомобиля. Буфер не деталь реализации, а необходимое условие асинхронного взаимодействия. Буфер - необходимая деталь реализации. Может роль буфера АЗС выполняет. Может пятьдесят китайцев с вёдрами таскают бензин от заправщика к Вашему авто. Деталь необходимая, но не существенная. Если же Вы настаиваете именно на взаимодействии бензовоза с АЗС и именно на взаимодействии АЗС с Вашим авто - тоже вариант. Но в этом случае есть два независимых взаимодействия двух ёмкостей с третьей (причем взаимодействия строго синхронных), а говорить о синхронности/асинхронности процессов изменения кол-ва топлива в никак не связанных между собой бензовозе и Вашем авто - вообще смысла нет. Но асинхронность не означает обязательного требования неодновременности. Оно означает отсутствие зависимости от одновременности, необязательность одновременности. Не спорю. Всё верно. Пусть асинхронность будет "отсутствием обязательной одновременности", в противопоставлении "антисинхронности", которая суть "обязательное отсутствие одновременности". Однако же уже если имеется отсутствие одновременности - это значит, что уже есть и асинхронность, и "антисинхронность". А вот teras, увидев в определении "последовательность действий" (т.е. явную их "не одновременность", и даже более строгую "неодновременность") - почему-то высказался, что дескать об синхронности/асинхронности речь не идёт. К чему и были мои возражения. Ну и закончим, пожалуй, на этой радостной ноте :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 18:29 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛП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. И что удивительно - можно вызывать функции в любом порядке, но опять же никаких ограничений на тему потоков . Тоже смешная система. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 19:24 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 teras У меня нет большого желания спорить А зачем тогда пришли? Уходили же вроде бы? Или Вам понравилось? "Мужик, я не понял - ты охотник или педераст?" (с) анекдот Чтобы пояснить ситуации, объясняю, что deadlock между родительской и дочерней транзакцией не возможен (хинт - дочерняя транзакция наследует *все* блокировки родительской). На это я Вам уже отвечал. Если нет правила "child's lock wins" - то будет дедлок, и нафиг такие блокировки не нужны. Если есть правило "child's lock wins" - то дедлок разумеется невозможен. Дедлока не будет. Да и вообще ничего не будет - эти блокировки (между родительской и дочерней транзакциями) никем не будут замечены. Т.е. абсолютно никем. Родительская транзакция даже чисто теорерически не может упереться в дочерние блокировки (т.к. дочерняя уже закончена к тому моменту, когда код родительской исполняться продолжит), а если дочерняя транзакция упрётся в родительские - то она безусловно побеждает. Поведение ничуть не отличается от поведения при полном отсутствии блокировок между родительской и дочерней транзакцией. А если разницы нет - зачем платить больше? Опять получается, что нафиг такие блокировки не нужны. Скажите, сколько раз нужно Вам надо это повторить, прежде чем до Вас дойдёт? Второе, "декларировать" поведение транзакции - это выражения мнения программиста об уровне изоляции, что может отражать или не отражать реальное поведение транзакции и ее требования к уровню изоляции. Ржунимагу Как это "декларировать", но "может не отражать реальное поведение"? Дескать садись ка ты, Иван Царевич, на своего серого волка, бери в руки свои декларации, и скачи к такой-то матери, не будет тебе Serializable, хоть ты обдекларируйся по самое нехочу, будет только Read Uncommitted. Третье - запустить MSDN и помедтировать на тему поиска "ODBC AND thread", читая подобные стати: Не читайте подобные статьи :) Не потому, что статьи плохие, а потому, что Вы до них еще не доросли. MFC-шная реализация библиотеки доступа к данным не обладает св-вом thread safety, однако же обязательно найдется очумелая башка, которая попробует в эту библиотеку долбиться одновременно с разных потоков. Для таких сказано русским по белому - "не делайте так, а то снег башка попадёт, а если уж вынуждены лезть в один объект с разных потоков, то синхронизируйтесь сами с собой, дабы не дай бог не исполнить чего-либо одновременно". Для чего Вы эту цитату привели? Чего сказать хотели? Что на клиенте можно многопоточный код исполнять, в том числе пытаться использовать то, что на многопоточное использование не расчитано? Северный варвар способен не только сломать свой нефритовый стержень, но и поранить при этом руки. почему-же ... не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока? Да на клиенте вызывайте Вы что хотите и как хотите, хоть в одном потоке, хоть в пяти, хоть последовательно, хоть параллельно. Если клиента не обрушите своими действиями, то и хорошо. На сервере то обёрнутые в транзакцию действия все равно будут выполняться последовательно (а иначе это не транзакция). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 08:30 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох почему-же ... не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока? Да на клиенте вызывайте Вы что хотите и как хотите, хоть в одном потоке, хоть в пяти, хоть последовательно, хоть параллельно. Если клиента не обрушите своими действиями, то и хорошо. На сервере то обёрнутые в транзакцию действия все равно будут выполняться последовательно (а иначе это не транзакция). Опа! Ну слава богу, дошло наконец, что транзакции не связаны с потоками ни на клиенте, ни на сервере, а последовательное исполнение операций - единственное требование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 10:56 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохMFC-шная реализация библиотеки доступа к данным не обладает св-вом thread safety, однако же обязательно найдется очумелая башка, По вам видно, что вы не читали. В той-же статье, буквально в предыдущем абзаце: "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes.". Лох , если хотите, что-то еще сказать - подкрепляйте ссылками на источники, где подтверждается то, о чем вы говорите, ну или хотя-бы читайте документацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 11:05 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 в поисках "предыдущего абзаца" непонятно какой статьи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 12:13 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛПНу и закончим, пожалуй, на этой радостной ноте :)Ага :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 15:25 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
В качестве дополнительной идеи к обсуждению тынц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 23:22 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛПДа мне-то на эти потоки пофигу. Это именно Вы потоки зачем-то приплели в попытке оправдать непоследовательное исполнение операций: <...> 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)". Искать с применением фраз из прошлых постов - ни разу не сложнее, ну разве, что она будет второй в списке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 23:45 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
mir ЛПНу и закончим, пожалуй, на этой радостной ноте :)Ага :) Зато цирк какой. Я все время вспоминаю фразу, недавно попавшуяся мне на глаза: "если вы спорите с идиотом, не забудьте, что он в этот момент делает то же самое". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 23:49 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
shuklinВ качестве дополнительной идеи к обсуждению тынц Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Или у вас что-то другое на уме? mir , у меня еще к вам вопрос есть - вы сказали, что я не прав, но так и не сказали в чем. Любопытно, все таки - о чем речь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 00:09 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras shuklinВ качестве дополнительной идеи к обсуждению тынц Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Да, если поддерживать в каждой транзакции не более одной вложенной одновременно . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 00:26 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras shuklinВ качестве дополнительной идеи к обсуждению тынц Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Или у вас что-то другое на уме? mir , у меня еще к вам вопрос есть - вы сказали, что я не прав, но так и не сказали в чем. Любопытно, все таки - о чем речь?Какой смысл вам обращаться к человеку, которого вы только что публично назвали идиотом? А что до того, почему вы не правы -- я об этом писал сразу же: "teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы." Вы читать не умеете? Еще раз, вы писали: "Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются." Может, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 08:53 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
mirА что до того, почему вы не правы -- я об этом писал сразу же: "teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы." Вы читать не умеете? Видимо - нет. Точнее, не могу понять, в чем это расходится с моими утверждениями? Что вы понимаете говоря "последовательные операции"? Транзакции целиком или их составные операции? Я изначально утверждал, что элементарные операции в транзакции НЕ выполняются параллельно, но из этого не следует, что их нельзя инициировать ассинхронно. В чем я не прав? mirМожет, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения. Что-же вы так испугались? Все же просто: вы не спорьте - просто объясните, в чем я ошибаюсь. Без хамства и переходов на личности. Потому что ни, то ни другое - ничего не доказывает. И если вам какие-то рассуждения показались неверными - может лучше обсудить почему, чем так, а? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 09:50 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
shuklinВ качестве дополнительной идеи к обсуждению тынц О !!! У Шуклина появились ТРАНЗАКЦИИ ? В однопользовательской системе !!! или Инвестора нашел ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 09:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 teras Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 10:47 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
mir2 teras Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП ? Или вы знаете другой способ остановить подобное? Предложите, буду крайне признателен. Серьезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 11:05 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 teras Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой: Чего Вы врёте? Было Ваше утверждение о том, что две транзакции, вложенные в третью, могут конкурировать между собой. Здесь. Был мой вопрос о том, каким же это образом они могут конкурировать, если они исполняются последовательно и не пересекаются во времени. Здесь. Был Ваш ответ, что дескать очень просто, не все СУБД связывают транзакцию с потоком, и некоторые позволяют что-то там выбирать. Здесь. В ответ на это Ваше высказывание был вопрос SergSuper: "Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией". Здесь. Нафига Вы теперь утверждаете, что это не связано с основной темой? Именно что связано. Всё "ответвление темы о мультипоточности" возникло именно из-за Ваших высказываний о том, что откуда-то может возникнуть конкуренция между последовательно исполняющимися транзакциями, приплетанию (Вами же) сюда потоков, а в последствии еще и бредовому упоминанию (опять таки Вами) синхронности/асинхронности. Теперь Вы пытаетесь сделать вид, что никакие потоки не при чем, никакая синхронность не при чём, всё у Вас однопоточно? Да пожалуйста. Только нафига ж Вы по прежнему игнорируете высказывание о том, что хоть скольки поточное у Вас исполнение - в Вашем примере транзакции по прежнему исполняются не последовательно (а "попопеременно")? Транзакции вполне могут исполняться не последовательно, но только не внутри другой транзакции, ибо там не может быть никакого непоследовательного исполнения ничего вообще, и вложенных транзакций в частности. в этом абзаце, речь идет о совершенно типичных вопросах, возникающих при использовании потоков Вопросы - да, соверешенно обычные. Необычно лишь то, что утверждается, что сделан mutlithreading support, при том, что весь multithreading support придется делать самому программисту, использующему MFC. Я по меньшей мере указываю, откуда беру информацию Вам известно значение слова "ссылка"? Если нет, то зачем Вы его употребляете в своей речи, и тем более требуете от других? Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП? Или вы знаете другой способ остановить подобное? А Вы ограничьте своё рвение в высказывании чуши. Тем самым избавите других от необходимости объяснять Вам, почему сказанное Вами является чушью, а самого себя избавите от необходимости трактовки этих объяснений в качестве "придирок и хамства". Не хотите ограничивать своё рвение в деле высказывания чуши? Ваше право, продолжайте высказывать чушь. Только не обижайтесь тогда, если Вас как обоссавшегося щенка в эту чушь носом тыкать будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 12:32 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
2 Gluk (Kazan) О !!! У Шуклина появились ТРАНЗАКЦИИ ? В однопользовательской системе !!! А почему в однопользовательской системе не может (или не должно) быть транзакций? Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 12:36 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛП2 Gluk (Kazan) О !!! У Шуклина появились ТРАНЗАКЦИИ ? В однопользовательской системе !!! А почему в однопользовательской системе не может (или не должно) быть транзакций? Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :) Лох прав. Транзакция не зависит от количества пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 12:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛП2 Gluk (Kazan) О !!! У Шуклина появились ТРАНЗАКЦИИ ? В однопользовательской системе !!! А почему в однопользовательской системе не может (или не должно) быть транзакций? Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :) Ага, только здесь ботва все больше про изолированность в последнее время ;) Да и на счет дюрабельности в его поделии тоже вопросы были ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:01 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов ЛП2 Gluk (Kazan) О !!! У Шуклина появились ТРАНЗАКЦИИ ? В однопользовательской системе !!! А почему в однопользовательской системе не может (или не должно) быть транзакций? Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :) Лох прав. Транзакция не зависит от количества пользователей. Вы на продвигаемый ПРОДУКТ смотрели ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:02 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Вы на продвигаемый ПРОДУКТ смотрели ? Качаю. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:04 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Ага, только здесь ботва все больше про изолированность в последнее время ;) Изолированность я не упомянул просто потому, что в однопользовательской системе она совершенно точно есть, её не надо обеспечивать, ни транзациями, ни чем другим :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:10 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
teras mir2 teras Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Освежу вашу память. Теперь еще раз по теме. Попытайтесь понять, что если последовательность операций по определению должна выполняться последовательно (Op 1 -> Op 2 -> ... -> Op n ), то ни о каких параллельных потоках или процессах и речи быть не может. В начальный момент времени может выполниться только операция Op 1 . Op 2 начать выполнение не может, пока не завершилась Op 1 (см определение последовательного выполнения). И так далее. Ни в один момент времени ни одна операция не может начать выполнение, пока не завершилась предыдущая. А значит, в любой момент времени только одна операция из последовательности может выполняться. О каком же синхронном или асинхронном выполнении каких вообще потоков можно говорить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:30 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
ЛП2 teras Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой: Чего Вы врёте? Было Ваше утверждение о том, что две транзакции, вложенные в третью, могут конкурировать между собой. Здесь. Был мой вопрос о том, каким же это образом они могут конкурировать, если они исполняются последовательно и не пересекаются во времени. Здесь. Был Ваш ответ, что дескать очень просто, не все СУБД связывают транзакцию с потоком, и некоторые позволяют что-то там выбирать. Здесь. В ответ на это Ваше высказывание был вопрос SergSuper: "Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией". Здесь. А что-ж вы не процитировали мой ответ ? О том, что до того момента "речь шла о другой крайности"? Очевидно, что другая крайность к "несколько потоков в одной транзакции" это - несколько транзакций в одном потоке. Если хотите простой пример такого - пожалуйста. Берем ODBC или OCI, в ОДНОМ потоке открываем ДВА соединения (оба ассоциируют транзакцию БД с соединением) и затем, в том-же самом потоке используем поочередно то первое, то второе соединение. Хотя такой подход требует особой осторожности в программировании, ни ODBC, ни OCI НЕ ограничивают в таком использовании. Где здесь потоки и причем здесь потоки? И именно в том-же посте я и спросил о том, а почему, собственно, нельзя работать с одной транзакцией из РАЗНЫХ потоков. Это и стало веткой про потоки, ассинхронность и т.д. ЛПТолько нафига ж Вы по прежнему игнорируете высказывание о том, что хоть скольки поточное у Вас исполнение - в Вашем примере транзакции по прежнему исполняются не последовательно (а "попопеременно")? Хотелось бы знать, что вы имеете в виду, говоря транзакции исполняются попеременно? То, что одна транзакция обязательно завершается, прежде, чем начнется другая (про это мы уже выяснили)? Или то, что элементарные операции, составляющие одну транзакцию выполняется последовательно? О чем я написал в первом-же посте на эту тему? ЛПТранзакции вполне могут исполняться не последовательно, но только не внутри другой транзакции, ибо там не может быть никакого непоследовательного исполнения ничего вообще, и вложенных транзакций в частности. Вернулись на начало. Еще раз повторяю, что такая модель вложенных транзакций далеко не единственная, но она существует, причем не только в теории, но и на практике. Ссылку на BDB я уже приводил. Если она вам не нравится или не нужна - ваше дело, но это не значит, что это - чушь. В любом случае, мнению ребят из Беркли я доверяю больше, чем вашему, уж извините. ЛП Я по меньшей мере указываю, откуда беру информацию Вам известно значение слова "ссылка"? Если нет, то зачем Вы его употребляете в своей речи, и тем более требуете от других? Известно. Толковый словарь Orfo: Ссылка (сущ): 1) Пребывание ссыльного на поселении. 2) Выдержка из текста или указание источника, на который ссылаются. Я использую слово во втором значении. Кроме того, я знаю, что в компьютерном жаргоне есть ещё одно значение, в достаточной мере совпадающее со вторым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:41 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
mir teras mir2 teras Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Освежу вашу память. Спасибо за подсказку. Вы уж простите великодушно, если вы приняли это на свой счет. Да я и не заметил, где мы с вами спорили, да еще и настолько бурно, и не понял, каким боком эта фраза может относиться к вам? А написал я о моем споре с ЛП . Собственно, весь спор был моей ошибкой - не учел специфику пользователей . mirТеперь еще раз по теме. Попытайтесь понять, что если последовательность операций по определению должна выполняться последовательно (Op 1 -> Op 2 -> ... -> Op n ), то ни о каких параллельных потоках или процессах и речи быть не может. В начальный момент времени может выполниться только операция Op 1 . Op 2 начать выполнение не может, пока не завершилась Op 1 (см определение последовательного выполнения). И так далее. Ни в один момент времени ни одна операция не может начать выполнение, пока не завершилась предыдущая. А значит, в любой момент времени только одна операция из последовательности может выполняться. О каком же синхронном или асинхронном выполнении каких вообще потоков можно говорить? Безусловно вы правы. Но вы напрасно проводите параллель между этой моделью и моделью транзакции в БД. О том, приведенное мной что определение последовательности в БД, данное Ульманом, а не мной, не подразумевает упорядоченности, я уже упомянул . А значит, мы уже не укладываемся в ваше определение из за использованной вами зависимости между окончанием одной операции и началом другой (я правильно интерпретирую стрелочки?). Нетрудно представить, что это вполне применимо на практике - например, в ОДНОЙ транзакции мы обновляем данные в БД для РАЗНЫХ датчиков, каждый из которых идентифицируется первичным ключем, или вообще находятся в разных таблицах, время ожидания готовности датчика может изменяться, но не превышает некоторой известной величины. Пусть одна транзакция - требование архитектора приложения, и мы можем на него повлиять. Можно заметить, что в этом сценарии нам все равно в каком порядке пройдут эти операции, единственное, что нас интересует, это чтобы они выполнились все. Согласны? Кроме того, взаимодействие с внешним миром делает неэффективным синхронное исполнение операции опроса и обновления данных. Одно из возможных решений (конечно, есть и другие) - использовать нескольких потоков (по количеству датчиков) для выполнения опросов и писать данные раздельно в каждом потоке. Таким образом, часть укрупненной операции (считывание+запись) будет выполняться ассинхронно (считывание), часть - синхронно(запись). При таком решении можно говорить о потоках? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 14:57 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
terasСпасибо за подсказку. Вы уж простите великодушно, если вы приняли это на свой счет. Да я и не заметил, где мы с вами спорили, да еще и настолько бурно, и не понял, каким боком эта фраза может относиться к вам? А написал я о моем споре с ЛП . Ваш комментарий был ответом именно на моё сообщение, адресованное ЛП. Вы назвали нашу с ним мини-дискуссию цирком, и сравнили нас с идиотами. Как ещё это было понимать? terasБезусловно вы правы. Но вы напрасно проводите параллель между этой моделью и моделью транзакции в БД. О том, приведенное мной что определение последовательности в БД, данное Ульманом, а не мной, не подразумевает упорядоченности, я уже упомянул . Процитирую вновь то определение: "Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными." Приведенное определение содержит явно ошибку (перевода?). Дело в том, что "группа последовательных операций" -- фраза бессмысленная, поскольку понятие "последовательная операция" -- бессмыслица. Одна, отдельно взятая операция не может быть ни последовательной, ни непоследовательной. Поэтому правильным вариантом будет либо "группа последовательно выполняющихся операций", либо просто "последовательность операций". Но в таком случае, никакого внтреннего параллелизма быть не может, о чём я и говорил. Ваши рассуждения о возможности распараллеливания операция транзакции я понимаю, но в этом случае надо менять определение транзакции. В последовательности операций всё просто, никакой внутренней синхронизации не надо. А если транзакция перестаёт быть последовательностью, она становится "обычной" параллельной программой, в которой должны использоваться те или иные примитивы (мьютексы, семафоры, рандеву...) для синхронизации параллельных частей. Мне с этакой кашей работать бы не хотелось. И так проблем много, а еще заниматься параллельным программированием? Я знаю, что это такое, и сколько ошибок это несёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 17:03 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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Мне с этакой кашей работать бы не хотелось. И так проблем много, а еще заниматься параллельным программированием? Я знаю, что это такое, и сколько ошибок это несёт. Не хочу - это совсем не тоже самое, что "не могу". Я ведь не призываю так делать без необходимости, речь идет о принципиальной возможности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 18:38 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Просматривал сегодня презентации с сайта "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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2007, 22:54 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 Чистой воды дебилизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2007, 23:06 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2007, 23:28 |
|
||
|
nested transaction vs savepoint
|
|||
|---|---|---|---|
|
#18+
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 Да глубоко наплевать кто они там. Вложенные транзакции и дерево транзакций - фигня. Это уже не транзакции а синхронизаторы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2007, 09:16 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553230]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
286ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 377ms |

| 0 / 0 |
