Здравствуйте, Sinclair, Вы писали:

SM>> Если можно, поподробней.
S>Я только что привел пример того, как две транзакции пересекаются по данным. Такой риск есть, если в коде одного потока перемешаны обращения в разных контекстах транзакций. Делов-то — заселектили в одной, записали в другой. Всё даже будет работать, пока нагрузка не возрастет.

Нагрузка на что? Господа архитекторы, уточняйте! Если речь идет про то, что что запаралеллить работу чтения записи, то тут как минимум, еще учитывают время обработки данных. То есть делают три потока. На чтение, на обработку, на запись.

Как человек который целый месяц курил одну поделку с похожей архитектурой (бухали вместе с автором машины Тьюринга), мог сказать что если обработка очень тяжелая — читать и писать можно в одном подключении. Обработчик не успевает разгребать входящий поток данных, а не в состоянии насытить буфер писателя.

S>А если работа с транзакциями разведена по разным потокам, то нужно следить за синхронизацией работы с соединением — та самая нудная многопоточность, про которую писал Иван.

А нудная и мутная, при неграммотной архитектуре. Мы с Тьюрингом придумали как это дело развеселить. Очень "до простоты смешные" паттерны (это у меня архитектор в душе проснулся) были рождены. Представляешь пять лет не писал многопоточный приложений, а тут как только откомпилировалось — сразу заработало.

S>Это плохо масштабируемая архитектура. С точки зрения сервера, эти соединения почти всё время простаивают. Тем не менее, ему нужно держать ресурсы, ассоциированные с каждым подключением. Именно из-за этого изобрели connection pooling.

Про это тоже было мною сказано.

SM>> Всё это я к чему написал: проблема согласования времени жизни транзакции с временем жизни коннекта — это как бы совсем не проблема.
SM>> По крайней мере при использовании IB-based с соответсвующей архитектурой доступа она настолько ничтожна, что обращать внимание на неё не стоит.
S>Ну то есть детали реализации диктуют архитектуру?
S>Я про Interbase вообще преисполнен пессимизма. Имею богатый негативный опыт работы с ним. Я в курсе, что с тех пор много воды утекло; тем не менее, осадок остался.

Согласен, Interbase v5 (v6) как реализация — полный отстой. Он мне тоже жизнь покалечил. Однако "Firebird — наше все" (с) местный народ. То что он появился и в 2002 году уже мог тянуть большие БД — реальное событие. То что что он в состоянии тянуть на текущий момент — меня до сих пор восхищает.

Вот только знаешь, если задуматься. VC6 — тоже покалечил. К щастью был BCB3, а потом быренько появился BCB5. Так что микрософт мой C++ не сильно покалечил. А как появился VC8 — пересел на него. Но вот MSSQL 2005, который если и калечит, то несильно, когда появился? — правильно с начала 2006 года. Но мысля поперла еще в 98 году. Представляешь какая неприятность.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, SmlMouse, Вы писали:
SM>> Если можно, поподробней.
S> Я только что привел пример того, как две транзакции пересекаются по данным.
Этот пример не показателен, так как не имеет отношения к соединениям.
В точности то же самое можно сделать и с отдельным соединением на транзакцию.

S> Такой риск есть, если в коде одного потока перемешаны обращения в разных контекстах транзакций.
S> Делов-то — заселектили в одной, записали в другой.
То же самое и с отдельными соединениями.
Я пока не вижу аргументов, показывающих порочность подхода one-connection:many-transactions.

S> Всё даже будет работать, пока нагрузка не возрастет.
А вот тут пожалуйста поподробней.
Что будет, если нагрузка возрастёт?

S> А если работа с транзакциями разведена по разным потокам,
S> то нужно следить за синхронизацией работы с соединением — та самая нудная многопоточность, про которую писал Иван.
Это тоже не есть особая проблема.
Но пока мы обсуждаем однопоточную модель, поэтому от описаний я воздержусь.

S>>> Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.
SM>> Это преимущественно вопрос архитектуры клиентских библиотек.
SM>> Для IB/FB/YA обычно вообще открывается одно соединение на всё время жизни приложения, поэтому следить за закрытием соединения нет необходимости.
S> Это плохо масштабируемая архитектура.
В каком месте? Что в ней плохо масштабируется?

S> С точки зрения сервера, эти соединения почти всё время простаивают.
S> Тем не менее, ему нужно держать ресурсы, ассоциированные с каждым подключением.
S> Именно из-за этого изобрели connection pooling.
Не совсем только поэтому. Ещё и из-за стоимости открытия нового соединения.

S> Удержание соединения придумано не из-за Interbase, а из-за того, что сначала с ним работал только BDE, спроектированный для парадокса.
S> Уже потом пришлось для решения очевидных проблем прикручивать все эти костыли.
Ну, допустим с IB можно было изначально работать мимо BDE.

SM>> Так же открытвается пару read-only r-c транзакций для всяких сервисных нужд и фетч-запросов.
SM>> Все остальные write транзакции обычно нужны для конкретных операций, вытекающих из бизнес-логики, и там вступают в силу совсем другие принципы.
SM>> Всё это я к чему написал: проблема согласования времени жизни транзакции с временем жизни коннекта — это как бы совсем не проблема.
SM>> По крайней мере при использовании IB-based с соответсвующей архитектурой доступа она настолько ничтожна, что обращать внимание на неё не стоит.
S>Ну то есть детали реализации диктуют архитектуру?
Нет. Реализация сервера не накладывает ограничений на архитектуру приложения. Хочешь — one-connection:one-transactions, хочешь one-connection:many-transactions.
Вышеприведённая цитата — ответ на цитату о том, что много сил нужно тратить на поддержание соответствия транзакций и соединений.

S> Я про Interbase вообще преисполнен пессимизма. Имею богатый негативный опыт работы с ним. Я в курсе, что с тех пор много воды утекло; тем не менее, осадок остался.
Это имеет какое-то отношение к обсуждаемому вопросу?

Здравствуйте, Sinclair, Вы писали:

S>Я вот лет восемь тому назад послал накуй Interbase 5.5 и 6.0 за неотчуждаемые родовые травмы головы, и своего мнения по этому вопросу не поменял. Потому что его писали люди, которые под СУБД понимали что-то другое, чем я. Возможно, с тех пор Interbase вышел из транса и научился хотя бы корректно выполнять простейшие запросы, но я к нему до сих пор отношусь с крайним подозрением. Я уважаю его умение работать во встраиваемом режиме, но в моих приложениях как раз это малосущественно.

До этого был IB 4.0, у которого травм, привенесённых бурландом практически не было.
А была реальная масштабируемость (мог работать на 2+ процессорах с одной базой), реальная поддержка UDF и реальная устойчивость в работе.
Планировщик только был туповат, но его прощали прибиванием ручного плана гвоздиком.
На тот момент другого такого сервера по такой цене просто небыло.
Говоря обо мне, мой путь был таким: IB4.0->Yaffil->FB2.
IB 5.5 я просто смотрел, но ни нагрузестойкость, ни устойчивость у него нас не удовлетворили, из-за чего переход из IB4 на IB5x не состялся.
Про 6.0 — я ему благодарен только тем, что он дал толчек для появления Yaffil и FB. Собственно больше IB 6.x благодарить незачто.


Но это как бы не совсем относиться к обсуждаемой теме

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Кстати, говоря, программер в моей душе еще не умер — и если юзаешь IBProvider третьей версии, то можешь дочерние транзакции подцепить к уведомлениям основной транзакции (через ITransactionJoin) и при коммите основной транзакции, автоматически закоммитишь дочерние.
S>А, так речь идет про вложенные транзакции? Или таки про параллельно-независимые?

То о чем здесь говорят — независимые. Дочерние, это я сказал в смысле "вторичные" по отношении к "перворожденной". У них связь только общей подключение (так сказать труба) к базе данных.

То есть: есть подключение, от него порождают две транзакции. Вообще говоря, порождают не транзакции, а объекты, которые управляют транзакциями. У этих объектов (у их интерфейсов) есть методы типа StartTransaction. В OLEDB такие объекты называются сессиями. А подключение — источником данных. Если подумать о MSSQL, то его источник данных скорее всего представляет собой коллекцию подключений (которыми пользуются сессии). В этой коллекции, думается мне, всегда минимум одон подключение. Потому что есть ситуации с обращением к БД, когда сессия не создается. Например запрос информации о статусе подключения.

Что такое вложенные транзакции я отчасти представляю — моделировал на точках сохранения. В OLEDB управление вложенными транзакциями идет через ITransaction+ITransactionObject. Это уже уровень конкретной сессии.

Здравствуйте, Sinclair, Вы писали:

А>> TR1.Commit;
А>> TR2.Rollback;

S>Отлично. А вы, Дмитрий Валерьевич, между TR2.StartTransaction и TR1.Commit какие-то данные из TR2 в TR1 переносите? Если нет, то что мешает поставить TR2.StartTransaction после TR1.Commit?

а если мне надо читать одновременно и в TR2 и в TR1 ?

A>>А если да, то какая же тут нахрен изоляция, если вы в
A>>TR1 закоммитили изменения, зависящие от отроллбэканных изменений в TR2?
A>>Нонсенс получается, Дмитрий Валерьевич.

давайте не будем таким способом объяснять "ненужность" одновременно активных транзакций.
А также фантазировать кто куда и какие данные переносит — это уже выходит за рамки
обсуждаемого, и скорее относится к здравомыслию пишущегопрограмму.
Например, Вам же никто не запрещает в ОДНОЙ программе открыть ДВА коннекта и обмениваться данными
между ЭТИМИ транзакциями? Нет? Ну и славно.

Здравствуйте, _d_m_, Вы писали:

___>>>Офигеть, дайте две. Здесь вполне можно открыть второе соединение и там выполнить изменения справочника — какая здесь необходимость в параллельных транзакциях?

R>>Объясните уж неверным, какое такое офигенное технологическое преимущество мы получаем, открывая в данном случае второе соединение?

___>А какое офигенное технологическое преимущество мы имеем используя здесь параллельные транзакции?
___>Я хотел лишь сказать, что в параллельных транзакциях нет необходимостим — вот и все.

Да вот есть уже у меня одно подключение. Зачем мне второе создавать? Я хотел лишь сказать, что во втором подключении нет необходимости — вот и все.

Здравствуйте, IB, Вы писали:

КДВ>>Может хватит зацикливаться на MS SQL ?
IB>Может пора уже слезтьс IB и понять почему в нормальных серверах все по другому?

я не зацикливаюсь. насчет "нормальных" — Вас как, не смущает наличие
версионности в MS SQL 2005 ? А то странно, что Вы так реагируете
на ДРУГУЮ функциональность ДРУГИХ серверов.
Может что-нибудь в Оракле привести в пример, что "ненормально" в MS SQL?

Здравствуйте, Sinclair, Вы писали:

КД>>Но тем неменее. В Редмонде работают реальные люди, как в прочем и в борланде, и в команде FB.

S>Не, ну давайте теперь меряться, кто кого послал и кто кому гуру.

Да не я же не про шворцы. И их про их толщину с диаметром. А про то, что не надо кивать на умы Редмонда.

S>Interbase ...Я уважаю его умение работать во встраиваемом режиме, но в моих приложениях как раз это малосущественно.

На всякий случай скажу, что сам Interbase работать во встраиваемом режиме не умеет. Не, я понимаю, что для "других" — что IB, что FB, что Ya — это типа одно и тоже. Но в реальности это уже давно не так. Interbase — мне до сих пор не вдохновляет, пусть кто-нибуть другой его окучивает. У него появились интересные фишки, но фишки меня уже не интересуют. По крайней мере — в его исполнении

Здравствуйте, SmlMouse, Вы писали:

SM>До этого был IB 4.0, у которого травм, привенесённых бурландом практически не было.
SM>А была реальная масштабируемость (мог работать на 2+ процессорах с одной базой),
Ты хочешь сказать, что борланд его от этого отучил? Я вот наблюдал IB 5.5, который стабильно жрал ровно 25% от четырехпроцессорной машины.
SM>Планировщик только был туповат, но его прощали прибиванием ручного плана гвоздиком.
После знакомства с планировщиком MS SQL 2000 я перестал испытывать к IB даже тень уважения, а также разочаровался в гвоздиках и прибивании.

Здравствуйте, IB, Вы писали:

КДВ>>мне непонятны эти инсинуации в сторону уровней изолированности в IB.
IB>Мне непонятно, почему простой вопрос воспринимается как инсинуация?

потому что это подается с каким-то сарказмом.

КДВ>>в IB/FB транзакции реализованы в соответствии со стандартом и требованиями ACID.
IB>Нет, они не соответствуют стандарту, если уж на то пошло.

ок. какие будут аргументы, что не соответствуют?

я уже давал ссылку на достаточно старый документ, в котором IB упоминается.
http://emanual.ru/download/www.eManual.ru_538.html

КДВ>>p.p.s. snapshot и RC в IB/FB тот же самый, что и например в Оракле. Или в Африке.
IB>Как минимум RC — разный, у Оракла строже.

строже куда и чем?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, SmlMouse, Вы писали:

SM>>До этого был IB 4.0, у которого травм, привенесённых бурландом практически не было.
SM>>А была реальная масштабируемость (мог работать на 2+ процессорах с одной базой),
S>Ты хочешь сказать, что борланд его от этого отучил?
S>Я вот наблюдал IB 5.5, который стабильно жрал ровно 25% от четырехпроцессорной машины.

Да. Отучил.
В IB4.0 была классическая архитектура в том числе и под Win32 (nt 3.51 и выше).
Начиная с IB4.1 (это уже бурланд) она умерла. Бурланд перешел на суперсервер.
А вновь классик под Win32 возродился только в Yaffil, а потом уже в FB.

SM>>Планировщик только был туповат, но его прощали прибиванием ручного плана гвоздиком.
S>После знакомства с планировщиком MS SQL 2000 я перестал испытывать к IB даже тень уважения,
Угу. Только не забываем, что всё это было лет так за шесть до появления SQL2000.

S>а также разочаровался в гвоздиках и прибивании.
Я вот как-то не испытываю сильного разочерования от планировщика FB2.0

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, SmlMouse, Вы писали:

SM>>До этого был IB 4.0, у которого травм, привенесённых бурландом практически не было.
SM>>А была реальная масштабируемость (мог работать на 2+ процессорах с одной базой),
S>Ты хочешь сказать, что борланд его от этого отучил? Я вот наблюдал IB 5.5, который стабильно жрал ровно 25% от четырехпроцессорной машины.
Давно. Одна из фич IB7. 2003(?), кажется год

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

Здравствуйте, Sinclair, Вы писали:

S>Я написал. Все результаты изменений, сделанных в одной транзакции, будут сырыми данными для другой. Именно поэтому сервер не даст второй транзакции "увидеть" эти изменения.
S>Но клиент может перенести их руками.

гм. никто так делать не собирался. Одновременные транзакции в IB/FB обычно используют для одновременного чтения и модификации. Читаем справочник, создаем накладную. И т.п.

Кстати. Непонятно, почему даже открытие не просто двух транзакций, а двух соединений в одном приложении вызывает священный ужас.
Например, напомню, что в BDE использование TTable при работе с MS SQL вызывало открытие стольких соединений, сколько было TTable (если не больше). Потому что MS SQL не умел держать в одном коннекте два недофетченных открытых запроса (курсора).
Таким образом, даже когда у нас в приложении якобы был один коннект (TDatabase), то на самом деле коннектов было много больше.
И никто от этого не умер, ACID не нарушилась, и вообще.

Попробую еще раз описать суть спора.

утверждение — в IB/FB можно стартовать несколько транзакций одновременно в одном соединении.
контр-утверждение — это не нужно, т.к. непонятно зачем.
объяснение — чтобы когда требуется работать с ДВУМЯ транзакциями одновременно, не надо было
открывать 2 соединения (вместо одного).
контр-объяснение — это ересь, т.к. так можно нарушить ACID.

следовательно, приложение всегда должно иметь только одно соединение с сервером? Это постулат?

Здравствуйте, Sinclair, Вы писали:

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

Естессно, ибо в противном случае MSSQL просто издохнет.

Здравствуйте, SmlMouse, Вы писали:

SM>Как я понял, аргументов не будет?
Аргументов на что? Что ты хотел показать своим примером?

SM>Только вот почему-то в БД мессаги под моим аккаунтом не отправлялись, тогда как Test работал без проблем
Понятия не имею чтотам у тебя случилось, когда банят выдается совершенно конкретное сообщение.

Здравствуйте, Кузьменко Д.В., Вы писали:

КДВ>я не зацикливаюсь.
Не заметно.

КДВ> насчет "нормальных" — Вас как, не смущает наличие версионности в MS SQL 2005 ?
А почему меня это должно смущать?

КДВ> А то странно, что Вы так реагируете на ДРУГУЮ функциональность ДРУГИХ серверов.
Я реагирую на то, что особенность реализации одних серверов пытаются выставить как недостатки других.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Иван, в этой ветке не надо было обсуждать архитектуру.
Пока не коснулось архитектуры я и не вмешивался.

КД> В ней пытались прояснить вопрос про несколько независимых транзакций в рамках одного подключения.
Вот я и попытался выяснить зачем это надо. Внятно на этот вопрос ответить так никто и не смог.

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

КД>И знаешь почему? Потому что, то что у меня работает уже пять лет работает у удовлетворяет всем твоим вышеуказанным интересам, в свое время тоже вызывало на форумах кучу противоречивых суждений.
Байта ради. Я уже говорил, что одно рабочее решение — не аргумент, и даже не одно.

КД>Про то, где должна работать бизнес логика — у меня тоже есть очень "забавное" виденье.
И что?

КД>Но не в теме, которая вообще говоря касается специфики компонент доступа.
Она уже давно касается не этого.

КД>Да, Иван, здесь в IB/FB тоже пошли немного дальше.
В смысле, немного не туда?

КД> И ты не поверишь, в OLEDB это тоже прописано.
Конечно прописано, потому как это общий драйвер, рассчитаный под самые странные сценарии. А вот в .Net драйверах очень многие вещи намеренно выкинуты.

КД> А MSSQL — минусы.
Правильно, так и должно быть. из сиквельных драйверов сознательно и планомерно выкидывают все лишнее. Примечательна еще история с серверными курсорами.

КД>Её никто не обвиняет.
Собственно все началось с твоего наезда на сиквел.

КД>Это не проблемы — это, черт побери, его принципы.
Ну фиговые принципы, что ж теперь?

КД>Обусловленные тем что в 198-каком-то там году (когда, думаю, они и были сформулированы), мало кто вообще себе представлял что должен из себя представлять сервер БД и как с ним работать.
Вот к этому моменту уже все очень хорошо себе представляли. Просто ребята решили пойти своим путем.

КД>Мда... а если эти алгоритмы напрямую завязаны на базу данных? Ну там, читают из неё данные, склеивают, разваливают, анализируют, контролируют.
Ну и какие проблемы?

КД>Ваня, у этих "детей" вполне зрелая взрослая жизнь и по-паре собственных детей. Я про программные комплексы, а про физических людей
Ну и что? Я тоже уже не мальчик, к сожалению...

КД>Будь проще, и люди к тебе потянутся.
Да мне уже отбиваться пора...

Здравствуйте, Кузьменко Д.В., Вы писали:

КДВ>потому что это подается с каким-то сарказмом.
Мой сарказм исключительно в ответ на хамство. И смысл вопроса сарказм не изменяет.

КДВ>ок. какие будут аргументы, что не соответствуют?
Собственно стандарт. В FB нет Serializable уровня изоляции, единственного, строго прописанного в стандарте.

КДВ>строже куда и чем?
Строже при чтении. Оракл, в отличии от FB, при обнаружении того, что данные менялись с момента начала запроса, выполняет миниоткат и перезапуск запроса, в RC уровне изоляции. Таким образом RC запросы в Оракле более согласованные.

Здравствуйте, IB, Вы писали:

IB>Я реагирую на то, что особенность реализации одних серверов
IB>пытаются выставить как недостатки других.

Ой, кто бы говорил...

Здравствуйте, IB, Вы писали:

КДВ>>строже куда и чем?
IB>Строже при чтении. Оракл, в отличии от FB, при обнаружении того,
IB>что данные менялись с момента начала запроса, выполняет миниоткат и перезапуск запроса,
IB>в RC уровне изоляции. Таким образом RC запросы в Оракле более согласованные.

А может ты сперва ознакомишься с тем, что там и как в IB/FB,
прежде тем строить эфемерные теории?..