Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Create Procedure SomeProc
As
    Begin Transaction
        Select ...
        Insert ...
        Update ...
        Delete ...
    Commit Transaction
и использовать эту процедурину там, где мне она нужна, а уж об уровнях вложенности пусть сервер думает, у него голова большой.


Голова большой, но металлический :(
Логика вложенности процедур ой как далеко не всегда связана с логикой подтверждения транзакций. Так что разработчику включать голову ПОЛЕЗНО полюбому
28 сен 07, 11:32    [4729010]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
SergSuper
teras
вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

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

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

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

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

Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией[/quot] Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией?
28 сен 07, 20:24    [4733011]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Gluk (Kazan)
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна


Запись в логи - чтобы при откате транзакции не стирались ее следы из лога.
28 сен 07, 21:02    [4733054]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
Пьяный Лох
Это, простите, какая-то чушь.
Вы, похоже, непонимаете, что изоляция - это защита (требуемого уровня) исполняемой транзакции от изменений во внешнем мире, а вовсе не защита внешнего мира от изменений в транзакции.
Чушь, только потому, что не согласуется с вашими понятиями? Любопытно, одному не нравится упоминание блокировок, другому - простое описание (без учета 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 сен 07, 21:29    [4733107]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
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 сен 07, 00:10    [4733686]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
teras
SergSuper

Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией
Ну вообще-то речь шла о другой крайности ;-) Хотя у меня тоже вопрос: а почему собственно, это не является транзакцией?

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

Ну сами подумайте: один поток делает А=1, другой паралельно делает А=2. В итоге результат работы оказывается непредсказуем
29 сен 07, 12:52    [4734210]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
SergSuper
Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет из себя логическую единицу работы с данными.
Что-же, этого вполне достаточно для ответа. Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются. Возникает вопрос - что тогда последовательные операции? Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая. Думаю, с этим трудно не согласиться. Как и с тем, что это определение никоим образом не противоречит понятию потоков. Собственно, единственное, что нужно сделать на практике, чтобы добиться последовательности исполнения операций разных потоков в одной транзакции, в соответствии с этим определением - например, использовать что-то наподобие мютекса, выделенного на транзакцию или гарантировать последовательность алгоритмически.
Кстати, опять же, это не только теория. Та же пресловутая BDB, насколько я помню, именно так работает с транзакциями. При этом она еще и возлагают требование соблюдения последовательности на программиста.
SergSuper
Ну сами подумайте: один поток делает А=1, другой паралельно делает А=2. В итоге результат работы оказывается непредсказуем
Подумал. Здесь вы, говорите не о последовательных операциях, а, скорее, об упорядочивании операций или о непротиворечивости данных. Это всегда было и будет заботой программиста. Вы же не станете требовать предсказуемости значения операции A=random() mod 2 + 1? А это - аналог вашей модели.
SergSuper
И соответственно все остальные Ваши рассуждения тогда ничего не стоят.
Знаете, у меня тоже нет особого желания доказывать.
29 сен 07, 21:09    [4734715]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
teras
Как определяет Ульман и др. в книге Системы Баз Данных, полный курс, последовательные операции - это такие операции, что одна заканчивается до того, как начинается другая. Думаю, с этим трудно не согласиться. Как и с тем, что это определение никоим образом не противоречит понятию потоков. Собственно, единственное, что нужно сделать на практике, чтобы добиться последовательности исполнения операций разных потоков в одной транзакции, в соответствии с этим определением - например, использовать что-то наподобие мютекса, выделенного на транзакцию или гарантировать последовательность алгоритмически.
Кстати, опять же, это не только теория. Та же пресловутая BDB, насколько я помню, именно так работает с транзакциями. При этом она еще и возлагают требование соблюдения последовательности на программиста.

"После сборки тщательно обработать напильником"

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

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

Про random и непротиворечивость - на самом деле можно много спорить, но я думаю не стоит. Будем считать я этого не писал, тоже типа было лирическое отступление
30 сен 07, 00:07    [4734845]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
SergSuper
Если нужно еще и что-то делать на практике - то, извините, противоречит. Т.е. то что Вы сделаете при соблюдении требования последовательности (кстати а где гарантия что не сделаете ошибки?) еще можно назвать транзакцией, но такую конструкцию, предоставляемую СУБД (не знаю как это правильно назвать) - нет.
С точки зрения СУБД, последовательность операций - необходимое и достаточное требование для транзакции. Но вы правы, так, как подобные возможности нужны очень редко, вводятся дальнейшие ограничения чтобы сократить количество ошибок программиста. Кроме того, если они действительно требуются (а такое тоже бывает), можно реализовать достаточно неплохую аппроксимацию и в самой программе.
30 сен 07, 01:18    [4734903]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
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
1 окт 07, 08:20    [4736156]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Выбегалло
Gluk (Kazan)
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна


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


см. "маленькие зеленые пирамидки" :)
1 окт 07, 09:35    [4736272]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

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

Что-то Вы совсем в определениях запутались.
Как это "не идет речи о синхронности/асинхронности"? Именно об этом речь и идёт.
Операции либо выполняются последовательно, т.е. неодновременно, т.е. асинхронно, либо выполняются параллельно, т.е. одновременно, т.е. синхронно.
teras таки не прав, но не по той причине, что вы назвали. Вы зря равняете неодновременность с асинхронностью, а параллельность с одновременностью. Это не так, но не будем в это вдаваться.

Чтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам. teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы.
1 окт 07, 17:16    [4739916]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
2 mir
Вы зря равняете неодновременность с асинхронностью

Чего???
Эти слова - одно и то же. Просто одно слово - русское, а другое - греческое.

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

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

teras не прав

Да я ж не спорю :)
1 окт 07, 18:14    [4740273]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
mir
Чтобы более строго рассуждать об этом, давайте вспомним, что понятия синхронности/асинхронности вообще приложимы только к параллельным процессам. teras не прав, потому что фраза про принципиально последовательные операции параллелизм сразу из рассмотрения устраняет, а значит и рассуждения о синхронности/асинхронности становятся неприменимы.
Вот. Об этом я и твержу - потоки, синхронность/асинхронность - это понятия из области теории операционных систем, а транзакция, последовательность операции и пр. - это из области теории баз данных. И это - принципиально разные вещи. Настолько разные, что ни одна более/менее серьезная книга по БД не проводит таких параллелей.
Да вы сами попробуйте реализовать что-то подобное базе данных с транзакциями, скажем - на основании массива, с построчными блокировками, транзакции представлены в виде отдельных объектов, и вы легко поймете, что эквивалентность потока и транзакции - это только удобство, но никак не необходимость - последовательного исполнения операций вполне достаточно.
2 окт 07, 01:23    [4741353]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
Пьяный Лох
Если я не хочу слышать, что Вы мне говорите, то я могу заткнуть себе уши. А могу отрезать Вам язык. Требуемый результат достигнут, хоть и разными способами.
Да, это заметно.
Пьяный Лох
Вы попытались привязать понятие изоляции к тому, видимы ли незакомиченные изменения другим транзакциям? Это - чушь. Изоляция - она совсем про другое. Она определяет "видимость" в совсем другую сторону, и с совсем другими (более многообразными) критериями, согласно которым изменения видны либо не видны.
Не надо смешивать понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) и уровня изоляции (декларирование условий, при которых для данной транзакции свойство изоляции будет выполнено). Изоляция определяется взаимодействем транзакций, в частности - незакоммиченными операциями. Вы все время говорите про понятие уровня изоляции.

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

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

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

Пьяный Лох
Посмотрите тогда на BDB.

Благодарю. Вы написали достаточно, чтобы у меня не возникло ни малейшего желание смотреть на систему, где транзакциями называют что-то совсем на транзакции непохожее.
Что сказать? Если вас пугают возможности - действительно, не стоит использовать инструмент в принципе.
2 окт 07, 01:48    [4741363]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ЛП
2 mir
Вы зря равняете неодновременность с асинхронностью

Чего???
Эти слова - одно и то же. Просто одно слово - русское, а другое - греческое.
Во-первых, ваш перевод с греческого неточен:
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211605,00.html
asynchronous
-- 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.html
1) 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.
2 окт 07, 06:52    [4741426]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 teras
понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно)

О! Вторая попытка :)
Сравните её с первой Вашей попыткой: "свойство изоляции ... - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую."

Не надо смешивать понятия изоляции ... и уровня изоляции

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

Вы все время говорите про понятие уровня изоляции.

Этой напасти подвержены именно Вы, увы :)

SQL не определяет уровней изоляции DIRTY READ и SNAPSHOT.

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

А версионность - это один из способов достичь уровня SERIALIZABLE.

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

Причем здесь deadlock?

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

Что сказать? Если вас пугают возможности

Да нет, что Вы. Они меня смешат :)

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

2 mir
Во-первых, ваш перевод с греческого неточен:

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

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

Греческий смысл греческого слова Вы умудрились вычитать в толковом английском словаре? Браво

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

Нет, не видим. Ну не видим мы data transmition link и прочих different speed.
Поэтому 4-ое значение - нам не нужно, хоть Вы его и считаете более компьютерным :)
2 окт 07, 08:22    [4741493]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 teras
автор
Не надо смешивать понятия изоляции (свойство системы прогонять несколько транзакций одновременно, так, как будто они исполнятся последовательно) и уровня изоляции (декларирование условий, при которых для данной транзакции свойство изоляции будет выполнено).

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

Декларация Read Committed как способ достижения всеобщего Serializable. Браво
2 окт 07, 08:35    [4741517]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Пьяный Лох
Во-первых, если уж Вы беретесь обсуждать тонкости перевода с русского на греческий и обратно, то не стоит использовать в качестве аргументов толковые словари для китайского языка, японского языка, немецкого языка, и для английского языка - тоже не стоит.
А вы-то почему беретесь обсуждать тонкости перевода с русского на греческий и обратно? Вашу речь оправдало бы одно: если бы вы привели обоснование своего перевода. Поэтому не стоит критиковать другого за иностранные источники, коли у вас нет ни иностранных, ни русских, никаких.
Пьяный Лох
То есть смысл по гречески: «не привязанный ко времени», «не скоординированный во времени», а вовсе не «неодновременный».

Греческий смысл греческого слова Вы умудрились вычитать в толковом английском словаре? Браво
В толковом английском словаре я вычитал английский смысл греческого слова. Не нравится мой перевод для "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 взаимодействие есть, и оно асинхронное. Однако к реальной одновременности это взаимодействие не имеет отношения. Я могу заправляться в другое время, чем когда приезжает заправщик, а могу одновременно (забудем пока про технику безопасности, тут дело в принципе).
2 окт 07, 10:47    [4742043]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
Пьяный Лох
Ладно, надоело. Объяснять свою точку зрения можно только тогда, когда собеседник хочет услышать. У вас же пока видно только стремление принизить собеседника, используя сарказм и личные нападки, видимо вы считаете, что вас это возвышает.
2 окт 07, 11:31    [4742420]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
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
Ладно, надоело.

Жалко. Я надеялся, что Вы еще порадуете нас мудрыми определениями :)
2 окт 07, 12:09    [4742786]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ЛП
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 - увеличение количества бензина в Вашем бензобаке.
Идёт?
Нет. Здесь нет ничего лишнего. Без заправки (то есть буфера) асинхронное взаимодействие невозможно. Мне придется ждать, пока приедет заправщик, заправщику придется ждать, пока приеду я. А это совсем не то же самое. Поэтому дальнейшие ваши рассуждения несколько некорректны. Буфер не деталь реализации, а необходимое условие асинхронного взаимодействия.

Могу другой пример: если почтальон носит вам почту, пользуясь почтовым ящиком (он кидает, вы берёте), это асинхронное взаимодействие. Если он должен вручать вам почту лично в руки (как телеграммы), это синхронное. Это два принципиально разных подхода. Но асинхронность не означает обязательного требования неодновременности. Оно означает отсутствие зависимости от одновременности, необязательность одновременности.
2 окт 07, 17:52    [4745783]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
2 mir
То есть «асинхронный» значит не «противоположный одновременности» (это было бы antisynchronos), а скорее «не обладающий свойством одновременности» или «не требующий одновременности».

Возражение принято.

Русское же «неодновременный» гораздо категоричнее.

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

А вы от каких аномалий умудрились не увидеть разговор про потоки?

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

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

От аномалий "грязного чтения", вестимо :)

Нет. Здесь нет ничего лишнего. Без заправки (то есть буфера) асинхронное взаимодействие невозможно.

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

Буфер не деталь реализации, а необходимое условие асинхронного взаимодействия.

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

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

Но асинхронность не означает обязательного требования неодновременности. Оно означает отсутствие зависимости от одновременности, необязательность одновременности.

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

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

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

Ну и закончим, пожалуй, на этой радостной ноте :)
2 окт 07, 18:29    [4746024]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
ЛП
2 teras
Ладно, надоело.
Жалко. Я надеялся, что Вы еще порадуете нас мудрыми определениями :)
У меня нет большого желания спорить с аргументами типа "я так привык". Так-что предлагаю желающим действительно разобраться самим этим заняться. Чтобы пояснить ситуации, объясняю, что deadlock между родительской и дочерней транзакцией не возможен (хинт - дочерняя транзакция наследует *все* блокировки родительской). Второе, "декларировать" поведение транзакции - это выражения мнения программиста об уровне изоляции, что может отражать или не отражать реальное поведение транзакции и ее требования к уровню изоляции. Третье - запустить MSDN и помедтировать на тему поиска "ODBC AND thread", читая подобные стати:

MSDN
When 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.
И что удивительно - можно вызывать функции в любом порядке, но опять же никаких ограничений на тему потоков . Тоже смешная система.
2 окт 07, 19:24    [4746250]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 teras
У меня нет большого желания спорить

А зачем тогда пришли? Уходили же вроде бы? Или Вам понравилось?
"Мужик, я не понял - ты охотник или педераст?" (с) анекдот

Чтобы пояснить ситуации, объясняю, что deadlock между родительской и дочерней транзакцией не возможен (хинт - дочерняя транзакция наследует *все* блокировки родительской).

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

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

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

Третье - запустить MSDN и помедтировать на тему поиска "ODBC AND thread", читая подобные стати:

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

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

почему-же ... не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока?

Да на клиенте вызывайте Вы что хотите и как хотите, хоть в одном потоке, хоть в пяти, хоть последовательно, хоть параллельно. Если клиента не обрушите своими действиями, то и хорошо. На сервере то обёрнутые в транзакцию действия все равно будут выполняться последовательно (а иначе это не транзакция).
3 окт 07, 08:30    [4747236]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить