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

Откуда:
Сообщений: 293
Пьяный Лох
почему-же ... не говориться о необходимости вызывать методы типа SQLExecute(), SQLEndTran() и т.д. из одного потока?

Да на клиенте вызывайте Вы что хотите и как хотите, хоть в одном потоке, хоть в пяти, хоть последовательно, хоть параллельно. Если клиента не обрушите своими действиями, то и хорошо. На сервере то обёрнутые в транзакцию действия все равно будут выполняться последовательно (а иначе это не транзакция).
Опа! Ну слава богу, дошло наконец, что транзакции не связаны с потоками ни на клиенте, ни на сервере, а последовательное исполнение операций - единственное требование.
3 окт 07, 10:56    [4748060]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
Пьяный Лох
MFC-шная реализация библиотеки доступа к данным не обладает св-вом thread safety, однако же обязательно найдется очумелая башка,
По вам видно, что вы не читали. В той-же статье, буквально в предыдущем абзаце: "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes.". Лох, если хотите, что-то еще сказать - подкрепляйте ссылками на источники, где подтверждается то, о чем вы говорите, ну или хотя-бы читайте документацию.
3 окт 07, 11:05    [4748130]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
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 в поисках "предыдущего абзаца" непонятно какой статьи.
3 окт 07, 12:13    [4748672]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ЛП
Ну и закончим, пожалуй, на этой радостной ноте :)
Ага :)
3 окт 07, 15:25    [4750319]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
В качестве дополнительной идеи к обсуждению тынц
3 окт 07, 23:22    [4752305]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
ЛП
Да мне-то на эти потоки пофигу. Это именно Вы потоки зачем-то приплели в попытке оправдать непоследовательное исполнение операций:
<...>
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)". Искать с применением фраз из прошлых постов - ни разу не сложнее, ну разве, что она будет второй в списке.
3 окт 07, 23:45    [4752353]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
mir
ЛП
Ну и закончим, пожалуй, на этой радостной ноте :)
Ага :)
Зато цирк какой. Я все время вспоминаю фразу, недавно попавшуяся мне на глаза: "если вы спорите с идиотом, не забудьте, что он в этот момент делает то же самое".
3 окт 07, 23:49    [4752362]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
shuklin
В качестве дополнительной идеи к обсуждению тынц
Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Или у вас что-то другое на уме?

mir, у меня еще к вам вопрос есть - вы сказали, что я не прав, но так и не сказали в чем. Любопытно, все таки - о чем речь?
4 окт 07, 00:09    [4752398]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
teras
shuklin
В качестве дополнительной идеи к обсуждению тынц
Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions?

Да, если поддерживать в каждой транзакции не более одной вложенной одновременно
.
4 окт 07, 00:26    [4752412]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
teras
shuklin
В качестве дополнительной идеи к обсуждению тынц
Ммм... Не совсем понял... Предлагаете эту идею в качестве концепции nested transactions? Или у вас что-то другое на уме?

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

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

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

Еще раз, вы писали: "Как видите, речи о синхронности/асинхронности в определении не идет, значит, явно потоки не исключаются." Может, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения.
4 окт 07, 08:53    [4752788]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

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

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

mir
Может, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения.
Что-же вы так испугались? Все же просто: вы не спорьте - просто объясните, в чем я ошибаюсь. Без хамства и переходов на личности. Потому что ни, то ни другое - ничего не доказывает. И если вам какие-то рассуждения показались неверными - может лучше обсудить почему, чем так, а?
4 окт 07, 09:50    [4753012]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin
В качестве дополнительной идеи к обсуждению тынц


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

или Инвестора нашел ???
4 окт 07, 09:54    [4753044]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль.
4 окт 07, 10:47    [4753467]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
mir
2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль.
Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП? Или вы знаете другой способ остановить подобное? Предложите, буду крайне признателен. Серьезно.
4 окт 07, 11:05    [4753594]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
2 teras
Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой:

Чего Вы врёте?

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

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

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

в этом абзаце, речь идет о совершенно типичных вопросах, возникающих при использовании потоков

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

Я по меньшей мере указываю, откуда беру информацию

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

Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП? Или вы знаете другой способ остановить подобное?

А Вы ограничьте своё рвение в высказывании чуши. Тем самым избавите других от необходимости объяснять Вам, почему сказанное Вами является чушью, а самого себя избавите от необходимости трактовки этих объяснений в качестве "придирок и хамства".
Не хотите ограничивать своё рвение в деле высказывания чуши? Ваше право, продолжайте высказывать чушь. Только не обижайтесь тогда, если Вас как обоссавшегося щенка в эту чушь носом тыкать будут.
4 окт 07, 12:32    [4754248]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!

А почему в однопользовательской системе не может (или не должно) быть транзакций?
Атомарность, консистентность и дюрабильность ведь как-то надо обеспечивать :)
4 окт 07, 12:36    [4754284]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
ЛП
2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!

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


Лох прав. Транзакция не зависит от количества пользователей.
4 окт 07, 12:54    [4754445]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ЛП
2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!

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


Ага, только здесь ботва все больше про изолированность в последнее время ;)
Да и на счет дюрабельности в его поделии тоже вопросы были
4 окт 07, 13:01    [4754505]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Сахават Юсифов
ЛП
2 Gluk (Kazan)
О !!! У Шуклина появились ТРАНЗАКЦИИ ?
В однопользовательской системе !!!

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


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


Вы на продвигаемый ПРОДУКТ смотрели ?
4 окт 07, 13:02    [4754514]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
Gluk (Kazan)

Вы на продвигаемый ПРОДУКТ смотрели ?


Качаю. :)
4 окт 07, 13:04    [4754537]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
ЛП
Guest
Gluk (Kazan)
Ага, только здесь ботва все больше про изолированность в последнее время ;)

Изолированность я не упомянул просто потому, что в однопользовательской системе она совершенно точно есть, её не надо обеспечивать, ни транзациями, ни чем другим :)
4 окт 07, 13:10    [4754589]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
teras
mir
2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль.
Значит вы считате, что я вам нахамил? Уж извините, не помню такого.
Освежу вашу память.

Теперь еще раз по теме. Попытайтесь понять, что если последовательность операций по определению должна выполняться последовательно (Op1 -> Op2 -> ... -> Opn), то ни о каких параллельных потоках или процессах и речи быть не может. В начальный момент времени может выполниться только операция Op1. Op2 начать выполнение не может, пока не завершилась Op1 (см определение последовательного выполнения). И так далее. Ни в один момент времени ни одна операция не может начать выполнение, пока не завершилась предыдущая. А значит, в любой момент времени только одна операция из последовательности может выполняться. О каком же синхронном или асинхронном выполнении каких вообще потоков можно говорить?
4 окт 07, 13:30    [4754768]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
ЛП
2 teras
Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой:

Чего Вы врёте?

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

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

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

ЛП
Я по меньшей мере указываю, откуда беру информацию

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

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

Я использую слово во втором значении. Кроме того, я знаю, что в компьютерном жаргоне есть ещё одно значение, в достаточной мере совпадающее со вторым.
4 окт 07, 13:41    [4754867]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
mir
teras
mir
2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль.
Значит вы считате, что я вам нахамил? Уж извините, не помню такого.
Освежу вашу память.
Спасибо за подсказку. Вы уж простите великодушно, если вы приняли это на свой счет. Да я и не заметил, где мы с вами спорили, да еще и настолько бурно, и не понял, каким боком эта фраза может относиться к вам? А написал я о моем споре с ЛП. Собственно, весь спор был моей ошибкой - не учел специфику пользователей.

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

О том, приведенное мной что определение последовательности в БД, данное Ульманом, а не мной, не подразумевает упорядоченности, я уже упомянул. А значит, мы уже не укладываемся в ваше определение из за использованной вами зависимости между окончанием одной операции и началом другой (я правильно интерпретирую стрелочки?). Нетрудно представить, что это вполне применимо на практике - например, в ОДНОЙ транзакции мы обновляем данные в БД для РАЗНЫХ датчиков, каждый из которых идентифицируется первичным ключем, или вообще находятся в разных таблицах, время ожидания готовности датчика может изменяться, но не превышает некоторой известной величины. Пусть одна транзакция - требование архитектора приложения, и мы можем на него повлиять. Можно заметить, что в этом сценарии нам все равно в каком порядке пройдут эти операции, единственное, что нас интересует, это чтобы они выполнились все. Согласны? Кроме того, взаимодействие с внешним миром делает неэффективным синхронное исполнение операции опроса и обновления данных. Одно из возможных решений (конечно, есть и другие) - использовать нескольких потоков (по количеству датчиков) для выполнения опросов и писать данные раздельно в каждом потоке. Таким образом, часть укрупненной операции (считывание+запись) будет выполняться ассинхронно (считывание), часть - синхронно(запись). При таком решении можно говорить о потоках?
4 окт 07, 14:57    [4755471]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
mir
Member

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

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

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

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

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

Мне с этакой кашей работать бы не хотелось. И так проблем много, а еще заниматься параллельным программированием? Я знаю, что это такое, и сколько ошибок это несёт.
4 окт 07, 17:03    [4756462]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить