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

Пьяный ЛохMFC-шная реализация библиотеки доступа к данным не обладает св-вом thread safety, однако же обязательно найдется очумелая башка, По вам видно, что вы не читали. В той-же статье, буквально в предыдущем абзаце: "Beginning with MFC 4.2, there is multithreading support for the MFC ODBC classes.". Лох , если хотите, что-то еще сказать - подкрепляйте ссылками на источники, где подтверждается то, о чем вы говорите, ну или хотя-бы читайте документацию.

ЛПДа мне-то на эти потоки пофигу. Это именно Вы потоки зачем-то приплели в попытке оправдать непоследовательное исполнение операций:
<...>
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)". Искать с применением фраз из прошлых постов - ни разу не сложнее, ну разве, что она будет второй в списке.

mir ЛПНу и закончим, пожалуй, на этой радостной ноте :)Ага :) Зато цирк какой. Я все время вспоминаю фразу, недавно попавшуяся мне на глаза: "если вы спорите с идиотом, не забудьте, что он в этот момент делает то же самое".

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

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

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

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

mirМожет, я и идиот, но здесь именно вы продемонстрировали вполне идиотские рассуждения. Что-же вы так испугались? Все же просто: вы не спорьте - просто объясните, в чем я ошибаюсь. Без хамства и переходов на личности. Потому что ни, то ни другое - ничего не доказывает. И если вам какие-то рассуждения показались неверными - может лучше обсудить почему, чем так, а?

mir2 teras
Родной, вы сначала начинаете зверски хамить, а потом объектов своего хамства призываете не переходить на личности. Этакая двойная мораль. Значит вы считате, что я вам нахамил? Уж извините, не помню такого. Кроме того, вы считаете, что я и дальше должен был терпеть хамство и придирки ЛП ? Или вы знаете другой способ остановить подобное? Предложите, буду крайне признателен. Серьезно.

ЛП2 teras
Ответвление темы о мультипоточности возникло от моего вопроса, по сути, никак не связанного с основной темой:
Чего Вы врёте?

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

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

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

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

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

Я использую слово во втором значении. Кроме того, я знаю, что в компьютерном жаргоне есть ещё одно значение, в достаточной мере совпадающее со вторым.

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

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

О том, приведенное мной что определение последовательности в БД, данное Ульманом, а не мной, не подразумевает упорядоченности, я уже упомянул . А значит, мы уже не укладываемся в ваше определение из за использованной вами зависимости между окончанием одной операции и началом другой (я правильно интерпретирую стрелочки?). Нетрудно представить, что это вполне применимо на практике - например, в ОДНОЙ транзакции мы обновляем данные в БД для РАЗНЫХ датчиков, каждый из которых идентифицируется первичным ключем, или вообще находятся в разных таблицах, время ожидания готовности датчика может изменяться, но не превышает некоторой известной величины. Пусть одна транзакция - требование архитектора приложения, и мы можем на него повлиять. Можно заметить, что в этом сценарии нам все равно в каком порядке пройдут эти операции, единственное, что нас интересует, это чтобы они выполнились все. Согласны? Кроме того, взаимодействие с внешним миром делает неэффективным синхронное исполнение операции опроса и обновления данных. Одно из возможных решений (конечно, есть и другие) - использовать нескольких потоков (по количеству датчиков) для выполнения опросов и писать данные раздельно в каждом потоке. Таким образом, часть укрупненной операции (считывание+запись) будет выполняться ассинхронно (считывание), часть - синхронно(запись). При таком решении можно говорить о потоках?