Re[29]: А может вообще уйти с Firebird? - Компьютерные священные войны

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

P>>Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом.
IB>Ну вот надо прислушиваться к кругозору и излагаемому опыту, а не упираться в привычный сценарий.

Это должно быть взаимно.

С одной стороны.

С другой — FB-шники, как ты их тут окрестил, по определению не могут упираться в привычный сценарий — потому что на этом сервере этих сценариев — "до-жопы". Хочешь так. Хочешь эдак. Хочешь вообще по-другому. Кто-то взял на вооружение только одно. А кто-то, до текущего момента, эти вопросы (а как?) — вообще не беспокоили — что уместно, то и юзает. Об этом было достаточно недвусмысленно сказано. Очень много раз. Без навязывания — ты накуй никому из них нужен.

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

Один коннект — одна транзакция. В разных потоках. В DCOM сервере.

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

Один коннект — несколько одновременно живущих транзакций в одном потоке. Когда писал "движок" для управления обновляемым множеством в провайдере. Как один из вариантов — хочешь обновляй в той же транзакции что и выборка, хочешь в другой. Наверное, у каждого варианта есть и преимущества и недостатки. Мне по-барабану — оттестировал и забыл. Сам я обновляемые множества даже косвенно не использую. Но заработал достаточно много денег, продавая провайдер пользователям MSSQL, которые используют эти множества

Думаю, они вряд ли что там крутят в настройках — поэтому и грузят и обновляют в одной транзакции. А две транзакции — для тех кто точно знает чего он хочет.

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

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

Добавлю что имею представление о работе координатора распределенных транзакций MSSQL. И мне не нравится как он работает, но "в истерику" я от этого не в падаю. Упоминаю только потому, что под ним старт транзакции делается в одном потоке, а коммит в другом. Двухфазность его работы в упор не увидел. Может её там и не должно быть, а может это я туплю

---
Причин по которым не сериализуют транзакции друг за другом наверное много. Но я не буду тут гадать какие. И что для получения этих причин надо выпить/покурить. Я знаю только такие.

1. При жестком коммите (который без продолжения) автоматически закрываются курсоры открытых множеств. Если множество не довыбрано, но очень хочется поскорее изменить его (или не его...) содержимое и закоммить — пожалуйста делайте это в отдельной транзакции. Кстати говоря, даже если полностью множество выбрали — блобы и массивы у FB/IB закачиваются отдельными вызовами для которых нужна транзакция (желательно та, в которой получили их дескрипторы). Полагаю, ума хватит не возводить эту особенность в ранг бесконечной ущербности? — здесь только одни преимущества. Если интересно — у меня есть реальный пример.

Из-за блобов и из-за того, что некоторые компоненты доступа могут давать возможность читать их через потоки (типа IStream), нельзя "прям-сразу" коммитить автоматическую транзакцию. То есть если клиент бросил множество (для загрузки которого автоматически стартовали транзакцию), но удерживает указатель на объект чтения BLOB-а из этого множества — транзакция будет продолжать висеть. Потому что для чтения блоба нужна транзакция. За этим следит не сервер, а компоненты доступа / конечный клиент.

Кроме как из множеств, BLOB-ы могут быть получены через OUT-параметр хранимой процедуры. Так что даже если хранимая процедура вернула управление, коммитить её автоматическую транзакцию еще рано. Нужно закачать блобы, а закачка может быть отложена... (в голову пришел забавный сценарий, который я здесь показывал IT-у в 2002(?) году, когда обсуждали ADODB)

В результате, при наличии незавершенной транзакции может появится другая. В отношении MSSQL — и новое подключение, а для IB/FB —
просто еще одна транзакция.

Если этого еще не говорили другие, напомню — что старт и коммит транзакций на FB/IB — это полностью в руках клиентской части. То есть — либо "в руках" компонент доступа, либо "в руках" конечного ПО.

[лично я в своем конечном прикладном ПО не использую автоматические транзакции в принципе. И IBProvider тому подтверждение — по умолчанию там они отключены. Что привело к очень большому числу сообщений (порожденных в том числе и перебежчиками с MSSQL) что провайдер "не работает" если не указать в строке подключения "auto_commit=true" ]

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

---
Лично мне глубоко по-барабану кто как и чем юзает свою базу данных. Однако мой опыт подсказывает — что даже умудренные опытом люди, снисходительно ссылающиеся на свои промышленныех решения, могут наступить на тривиальные грабли. Типа чтения нескольких связанных записей в транзакции с уровнем изоляции "read-committed". Про "повторяемое чтение" они слышали, но не увязывали со своей задачей. Или делать это вообще в отдельных транзакциях, ненароком наступив на "автокоммитные" грабли. Иногда они возводят в ранг "абсолютной" истины свои идеи, потому что не знают про другие, знают о них "по-наслышке" или просто хотят что-то доказать. Забыв что доказать можно только одно — собственную глупость.

Сам я себя ох...ным экспертом по БД не считаю — использую вещи, уровень которых зачастую неоправдан в какой-то конкретной задаче. Типа всегда и только всегда — явный старт транзакций и изоляция "повторяемое чтение". Как показала жизнь — благодаря этому избежал очень большое число проблем. Однако, сумел придумать и реализовать несколько интересных вещей, которые "зацепили" других людей. Про другие сервера, когда становится интересны конкретные вещи — задаю другим конкретные вопросы. И как правило получаю вполне приличные ответы — без непрекрытого посыла нах.... в MSDN.

Так что, Иван, с кругозором у твоих "оппонентов" все нормально. Полагаю, что со способностью уважать "чужой образ жизни" — тоже.

Просто никто не ожидал, что ты будешь так (умышленно?) тупить. Причем не в профессиональном, а общечеловеческом смысле.

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

Коваленко Дмитрий.

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

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

S>>Здравствуйте, SmlMouse, Вы писали:
S>>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции не пересеклись по данным. Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.

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

В этой ветке, как я понимаю 9 из 10 — архитекторы. Ну как акушер с акушерами поделюсь решением, обеспечивающего синхронность коммита. Берешь интерфейс объекту, управляющего транзакцией. Пишешь реализацию, которая делегирует вызовы своих методов в список "настоящих" транзакций. И все. Никто ничего не забудет. Ну да. Конечно, можно взять готовое решение — MS DTC.

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

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

КД> И есть скрытое глобальное место, где таки хранятся готовые подключения. Называется пулом. Пулом подключений. Не можно, конечно, без пула — да ради бога — указываем "OLE DB Services=0" и вперед к тормозам

Ну, то есть в IB своего пула нет и поэтому они считают, что пихать в один коннект несколько транзакций это круто, я правильно понял?

КД>Мдаа... Берем тривиальную задачу — запись логического лога в базу данных.
Для записи лога есть 33 способа, не говоря уже о том, что писать лог практически в то же хранилище где лежат и основные данные не очень правильно.

КД>Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет.
То есть, две транзакции из одного потока могут видеть незакоммиченые данные друг-друга? Прости, но это уже не транзакции.

КД>Поэтому у этого протоколирующего объекта должна быть собственная (короткая) транзакция.
Угу, но она не должна видеть незакоммиченых данных основной.

КД>... Заявления что паралельные транзакции имееют смысл только в раздельных потоках очень похоже на требование работы с разными файлами исключительно в разных потоках.
Пока не привели ни одного сценария, где действительно необходимо приостанавливать действие одной транзакции и выполнять другую в том же потоке.
И таких сценариев нет. Объясню еще раз почему:
Единственный случай, когда это может потребоваться — это организовать обмен незафиксированными данными между двумя транзакциями в обход сервера. То есть, сервер нам это делать запрещает, а мы придумываем как это обойти. Почему сервер это запрещает — я писал.
Ребята, у вас нет ощущения что вы делаете что-то не то?

КД>... Иван, завязывай с линейным мышлением. На улице уже даже не объектно-ориентированное время. В один корпус кучу ядер интегрируют, а ты не можешь понять зачем несколько транзакций засовывают в одной трубе подключения.
Ты сам-то понимаешь, зачем это делаешь?

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

КД>Я просил тебя написать простенький пример, который подтверждает возможность старта параллельной транзакции без открытия нового подключения. Слив как, защитывать?
MSDN открой.

КД>Иван, с тобой тяжко общаться...
Привыкай.

КД> Понимаешь, Firebird это сервер для людей у которых как-то более продвинутая способность к восприятию мира
Вот тут у меня серьезные сомнения. Я бы скорее использовал термин "измененное сознание".

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, <Аноним>, Вы писали:

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

IB>>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении?
IB>>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.

А>Абисняю. Все ОЧЕНЬ ПРОСТО.
А>Есть один TDatabase на приложение.
А>В каждой форме где есть запросы есть как минимум одна транзакция. она стартуется/коммитится в соответствии в логикой работы запросов на этой форме. И меня совершенно не волнует при этом что какой-то другой модуль может что-то сделать с транзакией этой формы — потому что они просто ее не видят

С чьей, простите, транзакцией?

Неужели кто-то еще пользуется продуктами Borland?

Тут, понимаешь, повсеместное DDD, OR/M, IoC ... а у Вас формочки мучаются несварением транзакций...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Привет, Ромашка!
Вы пишешь 19 сентября 2007:

>> Параллельные транзакции?

Р> Это что-то в Firebird перемутили.
Р> Транзакции параллельными и перпендикулярными быть не могут.

Да что ты?! Да как же так?! Как же жить после этого?..

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

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

КД>>Не перегибай палку

IB>Я вообще с палками не очень...

КД>>Блин, я вот не могу понять — в чем именно проявлется усложнение?
IB>Может ты просто по другому не пробовал?

Ну я может не пробовал. Точнее, я таким нюансам никогда внимание не придавал. Как удобно в конкретной задаче, так и делал. Однако разбирался с кодом клиентов IBProvider-a, ваявших для COM+, где именно так и делается. Ну дык там и подход и мышление другое. И есть скрытое глобальное место, где таки хранятся готовые подключения. Называется пулом. Пулом подключений. Не можно, конечно, без пула — да ради бога — указываем "OLE DB Services=0" и вперед к тормозам

КД>>IB, ни кто не заставляет обязательно делать многопоточное приложение.
IB>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении?
IB>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.

Мдаа... Берем тривиальную задачу — запись логического лога в базу данных. Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет. Ведь если это делать в основной транзакции, и она откатится, то записи протокола тоже откатятся. Поэтому у этого протоколирующего объекта должна быть собственная (короткая) транзакция.

Если тебе лень или ты принципиально не хочешь связываться с многопоточным приложением — то ради бога, держи эти две транзакции в одном потоке.

... Заявления что паралельные транзакции имееют смысл только в раздельных потоках очень похоже на требование работы с разными файлами исключительно в разных потоках. И реакция "С какого перепугу" — вполне подходит и к транзакциям.

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

КД>>И что же там делается?
IB>Где?

В функции реализации старта транзакции, которая автоматически пороздает новое подключение.

КД>>Тестили через OLEDB. Новая параллельная транзакция порождает НОВОЕ подключение

И на 2000 и на 2005
IB>MARS не поддерживается OLEDB, только .Net провайдером.

Хм. Ну да бог с ним с OLEDB. Я просил тебя написать простенький пример, который подтверждает возможность старта параллельной транзакции без открытия нового подключения. Слив как, защитывать?

КД>>Но практикующие ведущие собаководы иногда предлагают создавать по требованию именно транзакции. Понимаешь?
IB>И в чем проблема?

Не в чем, а в ком. Ты сказал

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

Я тебе ответил — никто тебе не навязывает число транзакций на одно подключение. И это есть хорошо.

КД>>Кроме того, сейчас, на сколько я понимаю, с появлением временных таблиц действующих на уровне соединения, весьма актульно что бы "параллельные" транзакции действительно оставались в рамках одного подключения. Потому что иначе — новая "параллельная" транзакция просто не увидит эту таблицу.
IB>А должна видеть? Скажем, в идеологии сиквела другая транзакция не должна видеть временные данные другой, думаю понятно почему.

И такая схема есть тоже. Одна транзакция подключения не видит временные данные другой транзакции этого же подключения.

IB>А вот зачем делать так чтобы временные данные можно было видеть — не понятно.

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

И между нами девочками говоря, MSSQL тоже развивается именно в этом направлении, реализовав версионную архитектуру, этот MARS, возможность писать на чем угодно логику уровня базы данных.

Но пока, та модель БД которая 5 лет и 4 дня, работает в нашей Липецкой недвижимости, не сможет в чистом виде работать ни на Оракле, ни на MSSQL. А только на IB-подобном сервере

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

IB>Ты серьезно думаешь, что если требоания ACID нарушатся на клиенте, а не на сервере БД, то в конечном итоге данные окажутся в более согласованном состоянии?

Иван, это передергивание. Для того, чтоб "обойти ACID" на клиенте наличия двух одновременных транзакций не требуется — достаточно просто запомнить состояние одной из них.

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

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

T>>Мне всегда казалось, что ACID — это гарантии именно сервера относительно данных.
IB>Ты ошибался.
Вполне может быть.
В таком случае, привиди ссылки на стандарты и документацию, которые подтверждают твоё утверждение.
Устроют ссылки на стандарт SQL 2003 или на онлайн документацию по любому серверу. С точностью до абзаца.
Идеально было бы ещё запрстить сюда цтатау, однозначно подтверждающую твою правоту.

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

T>>Если рассмотреть твой ответ, то ни один снервер просто не в состоянии предоставить эти самые гарантии, что бы не написал разработчик.

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

... << RSDN@Home 1.2.0 alpha rev. 760>>

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

П>>Что делать, такая вот уж плохая система, бывает иногда, что требуются и такие.
IB>Нет, не требуются.

Бороться со святой верой не намерен — это личное дело каждого верующего.

IB>Ну у вас ребята и каша. Вы меня даже не читаете.
IB>Я утверждал, что использование "параллельных" транзакций из одного потока — любят использовать почему-то только любители FB.

...тем более когда оппонент постоянно переводит тему.

T>>Ведь для любого сервера можно написать клиента, который их (*) нарушит.
IB>Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.

(*) ACID

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

Теперь вот потоки еще зачем-то приплел, еще немного — и до гетерогенных запросов докатимся... В общем нафиг такой спор, хочешь считать всех программистов firebird тупорылыми придурками, считаешь устройство MSSQLя (да благославит его аллах и приветствует) единственно верным — это твое личное дело, а я пас.

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

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

КД>- потому что на этом сервере этих сценариев — "до-жопы". Хочешь так. Хочешь эдак. Хочешь вообще по-другому.
Собственно, отчасти в этом и проблема. Когда можно делать все, но нет понимания зачем и к чему это может привести, то это хуже чем иметь ограниченый, но понятный набор возможностей.

КД>А кто-то, до текущего момента, эти вопросы (а как?) — вообще не беспокоили — что уместно, то и юзает.
А вот это главная бедулька. Мало того, что делают не задумываясь, так еще и упираются, никого не слушая.

КД>Лично я понимаю и тех и других. И третьих. И тех кто работает в автокоммите — тоже, лентяев и самоубийц, понимаю. Полагаю, за все это время что пытаюсь постичь дао управления сервером базы данных, перепробовал или трогал все.
Я тоже понимаю. Я их всех прекрасно понимаю. И дальше что?
Видишь ли. Мне давно уже не интересны решения которые просто работают. Я могу про такие решания рассказать — индусы отдыхают, при этом вполне рабочие. Заставить работать можно практически все, если не дышать.
Интересны правильные архитектурные решения — стабильные, хорошо масштабируемые и легко сопровождаемые. И я делюсь своим опытом как такие решения получать. Я ни в коем случае никого не заставляю поступать именно так. Я лишь объясняю как делать не следует и почему. Меня можно не слушать, мне вообщем-то все равно, только хамить не надо.

КД>Причин по которым не сериализуют транзакции друг за другом наверное много. Но я не буду тут гадать какие.
То есть, лень задуматься? Или просто не интересно? Тоже забавная позиция, думать лень, но спорить будем до упора.

КД>1. Кстати говоря, даже если полностью множество выбрали — блобы и массивы у FB/IB закачиваются отдельными вызовами для которых нужна транзакция (желательно та, в которой получили их дескрипторы).
То есть, это особенность FB? Возвращаясь к началу спора, в чем тогда MS провинился, если ему это нафиг не уперлось?

КД>В результате, при наличии незавершенной транзакции может появится другая. В отношении MSSQL — и новое подключение, а для IB/FB -
КД> просто еще одна транзакция.
Байта ради. Конечный разработчик этого не заметит. С точки зрения производительности и ресурсов — тоже разницы никакой. Это просто особенности внутренней реализации. Так какой смысл обвинять MS что он делает по другому?

КД>Если этого еще не говорили другие, напомню — что старт и коммит транзакций на FB/IB — это полностью в руках клиентской части. То есть — либо "в руках" компонент доступа, либо "в руках" конечного ПО.
Ну это опять-таки проблемы FB, причем конкретные проблемы. Если MS и другие сервера могут себе позволить без этого обойтись, то это не их вина.

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

КД>Иногда они возводят в ранг "абсолютной" истины свои идеи, потому что не знают про другие, знают о них "по-наслышке" или просто хотят что-то доказать. Забыв что доказать можно только одно — собственную глупость.
Угу. Наблюдал тут недавно, ужас просто

Некоторые оппоненты иногда, ну просто как дети..

КД>Так что, Иван, с кругозором у твоих "оппонентов" все нормально. Полагаю, что со способностью уважать "чужой образ жизни" — тоже.
Незнаю-незнаю. Они заставили меня в этом всерьез засомневаться.

Здравствуйте, SmlMouse, Вы писали:
S>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции

SM>>>Для предметных областей было приведено как минимум два примера:
SM>>>1. Добавление клиента (T2) для изменяемого документа (T1)
S>>Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.
SM>Может быть как минимум две причины:
SM>1. Не возможности открыть ещё одно соединение
А что мешает?
SM>2. Спроектированная архитектура приложения
ХаХа.

S>>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?
SM>Глобально — ничему.
SM>Локально — я так и не понял, а чем плохо всё это делать из одного соединения.
Напомню, что вопрос был ровно наоборот — "зачем всё запихивать в одно соединение". Поклонники FB уже сотню постингов пытаются отстоять свое право чесать левое ухо правой ногой.
Пока что, на мой взгляд, неубедительно. Важность этой фичи как минимум преувеличена. Как максимум — предлагаемые примеры либо ведут к заведомо ошибочной архитектуре, либо непринужденно делаются на разных соединениях.

Еще раз объясняю: если у вас есть техническая возможность организовать несколько логических соединений поверх одного канала — замечательно. Но зачем заставлять программиста думать об этом — мне непонятно.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции
???

S>>>Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.
SM>>Может быть как минимум две причины:
SM>>1. Не возможности открыть ещё одно соединение
S>А что мешает?
Например, если сервер линкуется в приложение (full embeded), то несколько соединений без конкретных плясок открыть нет возможности.

SM>>2. Спроектированная архитектура приложения
S>ХаХа.
Забавный аргумент

S>>>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?
SM>>Глобально — ничему.
SM>>Локально — я так и не понял, а чем плохо всё это делать из одного соединения.
S>Напомню, что вопрос был ровно наоборот — "зачем всё запихивать в одно соединение". Поклонники FB уже сотню постингов пытаются отстоять свое право чесать левое ухо правой ногой.
S>Пока что, на мой взгляд, неубедительно. Важность этой фичи как минимум преувеличена. Как максимум — предлагаемые примеры либо ведут к заведомо ошибочной архитектуре, либо непринужденно делаются на разных соединениях.
Потому что:
1. Может, насоветуете альтернативную СУБД: 
* бесплатная; 
* параллельные транзакции;

2. Re[6]: 
 КДВ> Есть коннект. в его рамках можно одновременно стартовать несколько транзакций. 
IB: Вот это уже не логично.

S>Еще раз объясняю: если у вас есть техническая возможность организовать несколько логических соединений поверх одного канала — замечательно.
S>Но зачем заставлять программиста думать об этом — мне непонятно.
Не так. Есть техническая возможность это использовать.
Почему это использовать нельзя?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SM>>2. Ведение лога работы пользователя (работа в T1, лог в T2)
S>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?

Да ничему не противоречит, вот только те кто профессионально работает с FB/IB, знают о такой архитектуре как Классик-Сервер. И о последствиях этого отдельного подключения к базе.

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

Кстати говоря — насчет моветона "одного подключения". Уж поверь, при граммотной архитектуре приложения, ну никто не мешает как все время держать подключение, так и создавать его по требованию. В случае OLEDB, например, достаточно работать не с нативе-провайдером, а микрософтовкой надстройкой.

---
Очень надеюсь что сейчас не будет ответа "А! Так это это опять специфика, которая MS даром не впилась". Да это специфика, о которой, повторюсь, знает любой профессионал.

Если тут такие умные — можете подключиться к разработке сервера и продемонстрировать свою техническую подготовку в разработке супера третьей версии FB. Но боюсь статус архитекторов не позволит спуститься на такой уровень. Впрочем, Еманова уже вывернуло наизнанку программирование одно архитектора. И я его, очень хорошо понимаю

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

S>Здравствуйте, SmlMouse, Вы писали:
S>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции

"Чтобы что"??? Чтобы не они не ступили друг другу на йайца?

С точки зрения конечной целостности данных, если они наступят в одном подключении — наступят и в разных.

S>Еще раз объясняю: если у вас есть техническая возможность организовать несколько логических соединений поверх одного канала — замечательно. Но зачем заставлять программиста думать об этом — мне непонятно.

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

Здравствуйте, 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>>До этого был 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

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

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

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

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

SM>>Хорошо. Ответь на простой вопрос.
SM>>В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку):
WH>В данном коде tr1 видит данные которые появились в базе после того как началась tr1.
WH>Те нарушена изоляция.
Если я добавлю, что tr1 стартанута в режиме RC, вы останетесь на своем мнении?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

П>> Бороться со святой верой не намерен — это личное дело каждого верующего.

IB>Ок, верьте..

П>>...тем более когда оппонент постоянно переводит тему.

IB>Я не меняю, это вы за темой не следите.
IB>Ты в чем-то не согласен с процитированным текстом?

П>> Теперь вот потоки еще зачем-то приплел,
IB>Я приплел?! Ребята, у вас какая-то фатальная проблема с отслеживанием хода дискуссии...

П>> В общем нафиг такой спор, хочешь считать всех программистов firebird тупорылыми придурками,
IB>Ну, к тому чтобы сформировалось такое мнение, в этом топике было приложено очень много усилий..

Зачем Вы тратите свое время? Спорить с фанатиками firebird бесполезно. Для них FB это единственная правильная СУБД и точка.
Не пытайтесь их переубедить — только реалии жизни с этим справятся.

... << RSDN@Home 1.2.0 alpha rev. 746>>

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

AC>О! Пионеры начали длиной мериться.

AC>Ну-ну, продолжайте.
AC>Ведь TCP, он именно для того чтоб пользовать "...пулинг кратковременно используемых соединений,
AC>и трактовка базы как штуки, которую ты изредка беспокоишь своими просьбами что-то сделать."
AC>Цирк снова с нами. Это радует.

Ну конечно, враги повсюду. И TPC сделали агенты MS тире противники FB. Только зачем там Oracle и DB2? Чем они провинились перед FB? Рекомендую создать сайт по измерению производительности параллельных "транзакций" в одном соединении.

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

IB>Интересны правильные архитектурные решения — стабильные, хорошо масштабируемые и легко сопровождаемые. И я делюсь своим опытом как такие решения получать. Я ни в коем случае никого не заставляю поступать именно так. Я лишь объясняю как делать не следует и почему. Меня можно не слушать, мне вообщем-то все равно, только хамить не надо.

Иван, в этой ветке не надо было обсуждать архитектуру. В ней пытались прояснить вопрос про несколько независимых транзакций в рамках одного подключения. В IB/FB такое есть с самого рождения. У других серверов — это моделируется. MARS, из-за которого все и покатилось, получается вообще ни при чем — примеров, которые можно просто взять и потестить, так и не привели.

КД>>Причин по которым не сериализуют транзакции друг за другом наверное много. Но я не буду тут гадать какие.
IB>То есть, лень задуматься? Или просто не интересно? Тоже забавная позиция, думать лень, но спорить будем до упора.

И знаешь почему? Потому что, то что у меня работает уже пять лет работает у удовлетворяет всем твоим вышеуказанным интересам, в свое время тоже вызывало на форумах кучу противоречивых суждений. От того что "это не удовлетворяет классическим правилам проектирования", до "это просто не заведется на текущем железе. типа очень тяжелое". А потом, один уважаемый архитектор из одной очень крупной IT-компании, был очень неприятно удивлен, когда узнал что его опередили, лет так на восемь. Причем не на Оракле, а на каком-то странном сервере по названии Firebird. Потом, чтобы хоть как-то оправится, этот забавный старикан начал обвинять меня в использовании "файл-серверной" архитектуры, что может вывести из равновесия кого угодно

Про мое отношение к репликации — ты наверное помнишь (август 2005 года)

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

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

КД>>1. Кстати говоря, даже если полностью множество выбрали — блобы и массивы у FB/IB закачиваются отдельными вызовами для которых нужна транзакция (желательно та, в которой получили их дескрипторы).
IB>То есть, это особенность FB? Возвращаясь к началу спора, в чем тогда MS провинился, если ему это нафиг не уперлось?

Да, Иван, здесь в IB/FB тоже пошли немного дальше. И ты не поверишь, в OLEDB это тоже прописано. Причем у IB/FB (как в отчете о навороченной железяки) напротив каждого пункта стоит плюсик. А MSSQL — минусы. Забавно, но это факт (полагаю из за специфики обмена с сервером). Есть и отложенное чтение, нет ограничений на порядок чтения колонок с блобами и нет ограничений на число открытых потоков через которые BLOB-ы грузятся. По умолчанию, ясный пень, компоненты доступа могут грузить все и сразу. Хотя, если опуститься на уровень пониже, ADODB запрашивает значения колонок по отдельности. Поэтому если ты не будешь лезть к Value колонки с BLOB-ом, блоб просто не будет загружен. Мелочь, а приятно.

Вообще говоря компоненты доступа (их интерфейсы), могут как полностью отупить сервер, так и наоборот раскрыть весь его потенциал. Вот за что я люблю OLEDB и сниму шляпу перед его авторами — они не отупляют. Но если взять первоначальный DBExpress, рожденного как минимум после недельного запоя — у меня самые негативные чувства. ADO.NET хоть отчасти и похоже, но реально граммотнее спроектировано.

КД>>В результате, при наличии незавершенной транзакции может появится другая. В отношении MSSQL — и новое подключение, а для IB/FB -
КД>> просто еще одна транзакция.
IB>Байта ради. Конечный разработчик этого не заметит. С точки зрения производительности и ресурсов — тоже разницы никакой. Это просто особенности внутренней реализации. Так какой смысл обвинять MS что он делает по другому?

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

КД>>Если этого еще не говорили другие, напомню — что старт и коммит транзакций на FB/IB — это полностью в руках клиентской части. То есть — либо "в руках" компонент доступа, либо "в руках" конечного ПО.
IB>Ну это опять-таки проблемы FB, причем конкретные проблемы. Если MS и другие сервера могут себе позволить без этого обойтись, то это не их вина.

Это не проблемы — это, черт побери, его принципы. Обусловленные тем что в 198-каком-то там году (когда, думаю, они и были сформулированы), мало кто вообще себе представлял что должен из себя представлять сервер БД и как с ним работать. Решили, что управление лучше не размазывать. Добавить всегда успеют, в удалить... Самое что поразительное, если не сравнивать с навороченным OLEDB, интерфейс клиента получился достаточно граммотным. Но по сравнению с OLEDB — отдыхает (что и понятно — процедуры vs объекты), хотя и в состоянии заполнить его изнутри.

Для тебя наверное это дико — но это не значит, что другие не воспринимают это "как само собой разумеющееся". Сейчас прикрутят хранимые процедуры/триггеры на "яве и пр." может Дима Еманов и скажет — "да будут собственные транзакции на уровне сервера".

КД>>2. Просто не в состоянии проконтролировать и гарантировать что во время работы линейного алгоритма какая-та его настраиваемая часть (то есть та, которая может модифицироваться после сдачи приложения в эксплуатацию — скрипты/внешние компоненты) вдруг не решит, что ей край какие-то (служебные?) данные прочитать в собственной независимой транзакции. А может это вообще изначально по-сценарию так надо. Или это очередной студент, который решил что это круто, или ему, допуская "к телу", не объяснили базовых принципов.
IB>Нет никаких проблем вынести настраиваемые части за рамки внутренних транзакций.

Мда... а если эти алгоритмы напрямую завязаны на базу данных? Ну там, читают из неё данные, склеивают, разваливают, анализируют, контролируют. Иван, меня "как архитектора", не волнуют детали — я только придумал как такие "компонентые" алгоримы конструировать. И кстати юзаю для этого технологии того же MS.

А если мне понадобить запретить этим кусочным алгоримам заниматься самодеятельность — я тоже знаю как это сделать. И в спецификациях MS — для этого есть подходящие/похожие конструкции.

КД>>Иногда они возводят в ранг "абсолютной" истины свои идеи, потому что не знают про другие, знают о них "по-наслышке" или просто хотят что-то доказать. Забыв что доказать можно только одно — собственную глупость.
IB>Угу. Наблюдал тут недавно, ужас просто

Некоторые оппоненты иногда, ну просто как дети..

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

КД>>Так что, Иван, с кругозором у твоих "оппонентов" все нормально. Полагаю, что со способностью уважать "чужой образ жизни" — тоже.
IB>Незнаю-незнаю. Они заставили меня в этом всерьез засомневаться.

Будь проще, и люди к тебе потянутся.

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

SM>Ну, с исторической точки зрения FireBird тут совсем ни при чем.
SM>"Перемутил" Джим в незапамятные времена.
SM>За что многие люди (и я) ему благодарны.

ничего он не "перемутил".

все кстати, очень логично. Есть коннект. в его рамках можно одновременно
стартовать несколько транзакций. Как минимум, чтобы не открывать каждый
раз новый коннект если потребуется стартовать транзакцию.
Дальше. В транзакции живут запросы. Могут жить одновременно много открытых запросов.
Потому что хэндлы. Получил хэндл транзакции на клиенте, и делай с ним что хочешь.
можно второй получить, и т.п.

Никаких противоречий не вижу. Более того, все это отлично кладется
на нынешнюю концепцию Database->Transaction->DataSource. 1->n->m

А если использовать концепцию "трубы", то есть коннекта в который
кидаются текстовые команды вида start transaction, fetch, то
разумеется, отличать fetch одного запроса от другого, или
запрос в одной транзакции от запроса в другой транзакции — это очуметь можно.

Отсюда разница в восприятии и непонимание сторон.

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

SM>>Которые и называются "параллельными".
IB>Нет, они последовательные. Транзакция не может начаться, пока не зафиксируется предыдущая, если так понятнее.

бред какой то.

еще раз.
TR1.StartTransaction;
...
TR2.StartTransaction;

TR3.StartTransaction;

TR2.Commit.

и все это В ОДНОМ КОННЕКТЕ. перемешанное в кучу. Почему и пишем про них как про "параллельные".

SM>> Так как в одном соединении в одно и то же время могут быть несколько активнывх транзакций.
IB>Нет в этом смысла. Нельзя так делать и не несет это никакой практической ценности, я уже устал писать почему.

почему в разных коннектах в транзакциях смысл есть, а в одном коннекте — нет?
Может хватит зацикливаться на MS SQL ?

... << RSDN@Home 1.2.0 alpha rev. 746>>

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

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

Пытаемся задавить интеллехтом?

Напомню, форум по программированию, а не по толкованию философских принципов.

Вижу три критерия определения преимуществ:
— Наличие возможности.
— Удобство использования.
— Расход ресурсов.

Возможно кто-то добавит еще.

По существу дела есть что сказать? Без философских терминов?

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

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

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

AC>Иван, а вот ежели я тебе скажу: "иногда лучше жевать, чем говорить!", ты меня забанишь?
Еще разок и да, пора банить. И вообще еще один впад не по делу и ветка во флейм, мне отдыхать надо.

AC>Интересно просто. А то некий kuj тут так и мелькает с этой фразой, так и мелькает...
Не, ребята, ваша фракция по очкам вне конкуренции.

AC>Иван, какое отношение имеют данные отфетченные на клиента, к состоянию транзакии?
Ты считаешь что если данные уехали на клиента то это уже вроде ка ки не транзакция?

AC>Подтвержденные, неподтверждённые... Проясни.
Да я уже устал пояснять, ей богу.
Вот если вечерком будет время может напишу развернуто, если вы меня окончательно не озлобите..

AC>Дык, где же, где же?
В ветке.

AC>Наводящие вопросы ты игнорируешь напрочь.
Я?!! Да это вы не наодин мой вопрос ответить не можете, вам почему-то сразу кажется, что обижают ваш любимый IB.

AC>Аргументов никаких, одни эммоции...

РЕбят, вы хотя бы себя читате? Про меня я уже даже не спрашиваю, но в ваших ответах хотя бы иногда попадаются мои цитаты..

AC>Слив засчитан.
Озлобил.

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

AC>Иван, транзакция живет на сервере.

Нда.. И эти люди говорят мне об огарниченности мышления и закостенелости взглядов..

Давай откроем учебник — транзакция это совокупность операций по переводу данных из одного согласованного состояния в другое. Где и как это происходит совершенно не важно. Для того, чтобы процесс сошелся и перевод произошел именно в согласованное состояние, должны соблюдаться требования ACID.
Ты серьезно думаешь, что если требоания ACID нарушатся на клиенте, а не на сервере БД, то в конечном итоге данные окажутся в более согласованном состоянии?

AC>Что там у клиента за щекой — серверу не интересно.
Вот собственно в этом и проблема. Именно эту простую мысль я и пытаюсь до вас донести. Если вы обойдете сервер и начнете обмениваться данными активных транзакций между собой, то сервер уже не сможет этот обмен проконтролировать.

AC>Ждем-с.
Тогда бросайте хамить.

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

kuj>Тут, понимаешь, повсеместное DDD, OR/M, IoC ... а у Вас формочки мучаются несварением транзакций...

Ты главное слюной не захлебнись.

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

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

Да почему нельзя-то? Нельзя считать подобные действия единой атомарной изолированной транзакцией — это да, но если бизнес-процессом такой цели и не ставится, то почему нет? И наоборот — кто мешает не делать так на Fb, если это действительно необходимо? Возможность есть, а пользоваться ей или нет — это уж каждый для себя решает сам, в каждом конкретном случае.

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

П>Да почему нельзя-то?
Я объяснил почему. Если до сих пор непонятно, то я бессилен.

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

П> И наоборот — кто мешает не делать так на Fb, если это действительно необходимо?
У FB-шников правда что ли комплекс какой? речь уже давно не про FB, а про архитектуру клиента.

П> Возможность есть, а пользоваться ей или нет — это уж каждый для себя решает сам, в каждом конкретном случае.

Эта возможность есть везде, но почему-то на других серверах это никому в голов не приходит.

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

IB>Потому что атомарная изолированная транзакция — очень удобная абстракция для описания бизнес-процесса.

Удобный != единственный. Строго говоря даже атомарность самого клиента не является необходимым условием — я, например, знаю систему, где приятие решения о допуске пользователя к выполнению некоего действия, определение параметров этого действия и собственно производство этого действия выполнялись тремя независимыми друг от друга приложениями. И как ты в этом случае предлагаешь посредством изолированности и атомарности их транзакций поддерживать непротиворечивость бизнес-процесса?

T>>Ведь для любого сервера можно написать клиента, который их нарушит.

IB>Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.

Очень спорное утверждение. Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы. Никаких фатальных последствий, кроме неудобства, это правда афаир не вызывало, но тем не менее...

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

P>Непраивльный пример.
Ну я не виноват, что он тебе не нравится.

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

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

P>Эээ, ну еси это было не ясно — Я. ИСПОЛЬЗОВАЛ. ОБА. ПОДХОДА.
Зачем? Какую задачу ты решал используя две активные транзакции из одного подключения и что мешало сериализовать эти транзакции?

P>И буду использовать дальше оба.
Ну и зря, тем более оба.

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

П> Удобный != единственный.
Кто бы спорил. Способов прострелить себе ногу пытаясь повеситься более чем достаточно.

П> я, например, знаю систему, где приятие решения о допуске пользователя к выполнению некоего действия, определение параметров этого действия
Это проблемы исключительно этой системы.

П> Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы.
И что же в этом примере обратного?

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

IB>Кто бы спорил. Способов прострелить себе ногу пытаясь повеситься более чем достаточно.

Слова, слова...

IB>Это проблемы исключительно этой системы.

Что делать, такая вот уж плохая система, бывает иногда, что требуются и такие. Но факт в том, что большая часть бизнес-процессов в ней не удовлетворяла требованиям ACID даже близко, не говоря уж о какой-то золотой пуле в виде правила "одно действие — один коннект". Тем не менее, несмотря на всю свою "идеологическую неправильность" система работала и полностью удовлетворяла заказчика (*). Не вижу причин, почему бы других заказчиков не должны удовлетворить обсуждаемые здесь параллельные транзакции, которые при правильном использовании гораздо более безопасны и надежны, чем описаная модульная мешанина.

П>> Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы.
IB>И что же в этом примере обратного?

В выделеном. Кто-то утверждал, что использование данных транзакции А в транзакции Б — это исключительно firebird-заморочки, насколько мне помнится, а настоящим крутым чувакам такое-де и в голову прийти не может. Однако же приходит, как ни странно, и при том весьма регулярно.

(*) Да, кстати — эта система тоже использовала не firebird.

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

P>>Непраивльный пример.
IB>Ну я не виноват, что он тебе не нравится.

Ну, а кто же еще виноват? Ты говоришь про какую-то систему, на Оракле, с неизвестной архитектурой и внутренностями, СЕРИАЛИЗОВАННЫМИ, вследствии архитектуры Оракла, транзакциями — привязать этот пример к теме топика можно лишь дофантазировав удобные тебе детали — технических фактов 0. Приведи, плз, подробности архитектуры той системы — что делают в той длинной транзакции, как там выполняются параллельные действия и т.п. Т.е. свяжи свой пример с темой.

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

Дурь ты всякую написал, прости за резкость. Даже теоретически нигде изолированность там не нарушается,
если транзакции уровня RC. А читая твои посты — появляется подозрения, что с уровнями изолированности ты знаком слабо — но боюсь показаться излишне самоуверенным и наглым — давай вместе перечитаем документацию, и еще раз, ВНИМАТЕЛЬНО, посмотрим, как и где, в моем примере, нарушается изолированность транзакций.

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

??? А никто и не говорил, что они там необходимы, или обязательны — они возможны и удобны.
О чем, собсно, и начинался топик.

P>>Эээ, ну еси это было не ясно — Я. ИСПОЛЬЗОВАЛ. ОБА. ПОДХОДА.
IB>Зачем? Какую задачу ты решал используя две активные транзакции из одного подключения и что мешало сериализовать эти транзакции?

Гм, мне что, в подпись вставить свои пример?
Скажи, ты ведь использовал где-либо схему с несколькими подключениями на одного клиента? Так вот, грубо говоря, там же я использовал одно подключение, но с несколькими транзакциями(напоминаю, это утрированный пример — там где реально нудно несколько подключений, например в сервере приложений, естественно пользуются раздельные подключения)

P>>И буду использовать дальше оба.
IB>Ну и зря, тем более оба.

Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом. К моему удивлению ты показываешь обратные качества — не разобравшись в вопросе, публично делать такие выводы?

Есть идея, давайте четко сформулируем предмет спора, и каждая сторона напишет статью по теме — ибо я не вижу, как иначе прекратить передергивания и неаргументированные заявления.

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

П>Что делать, такая вот уж плохая система, бывает иногда, что требуются и такие.
Нет, не требуются. Хотя бывает, что другой написать не получается — это да, это факт.

П> Не вижу причин, почему бы других заказчиков не должны удовлетворить обсуждаемые здесь параллельные транзакции, которые при правильном использовании гораздо более безопасны и надежны, чем описаная модульная мешанина.
Тем что они опасны и не надежны.

П> Кто-то утверждал, что использование данных транзакции А в транзакции Б — это исключительно firebird-заморочки,
Ну у вас ребята и каша. Вы меня даже не читаете.
Я утверждал, что использование "параллельных" транзакций из одного потока — любят использовать почему-то только любители FB.

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

P>Ну, а кто же еще виноват?
Ты конечно, так как не слушаешь аргументов, которые тебя не устраивают.

P> Ты говоришь про какую-то систему, на Оракле, с неизвестной архитектурой и внутренностями, СЕРИАЛИЗОВАННЫМИ, вследствии архитектуры Оракла, транзакциями
Ты даже не читаешь того что тебе пишут, я уже не говорю о том, чтобы попытаться понять. Это был пример про длинные транзакции, а не сериализованные — длинные, понимаешь?

P> Даже теоретически нигде изолированность там не нарушается,
Точно, не читаешь, так я и думал.

P> как и где, в моем примере, нарушается изолированность транзакций.
Если в твоем примере изолированность транзакций не нарушается, то нет никакой причины, по которой их нельзя было бы сериализовать. Это задачка для первокласника. Таким образом, возвращаясь к началу спора, необходимости в параллельных транзакциях из одного потока — нет.
Более того, возвращаясь к твоей задачке, у тебя обращение к БД идет в UI-ном потоке?

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

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

P>Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом.
Ну вот надо прислушиваться к кругозору и излагаемому опыту, а не упираться в привычный сценарий.

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

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

П> Бороться со святой верой не намерен — это личное дело каждого верующего.

Ок, верьте..

П>...тем более когда оппонент постоянно переводит тему.

Я не меняю, это вы за темой не следите.
Ты в чем-то не согласен с процитированным текстом?

П> Теперь вот потоки еще зачем-то приплел,
Я приплел?! Ребята, у вас какая-то фатальная проблема с отслеживанием хода дискуссии...

П> В общем нафиг такой спор, хочешь считать всех программистов firebird тупорылыми придурками,
Ну, к тому чтобы сформировалось такое мнение, в этом топике было приложено очень много усилий..

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

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

A>Хм. Не понял — мессага не ушла или кто-то снова балуется? Хотя может и браузер глючит, но прецеденты были. Повторюсь тогда.

A>>> Я процитировал на всякий случай.
IB>>О чем речь-то?
A>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?
Тебе же написали — сырые данные поставляет клиент. Одной рукой он пишет в T1 некие данные, читает что-то там из T1 и второй рукой пишет в T2. С точки зрения T2 эти данные являются сырыми, потому что коммита T1 еще не произошло. Если T1 откатить, а T2 закоммитить, то в базе окажется результат никогда не существовавших вычислений.

Если делать наоборот — в процессе сервировки T1 быстренько выполнить T2, то риск несколько снижается. Но и смысл использовать для T2 то же самое соединение минимален.
Напомню, что логическое соединение — это не только канал, но и набор всяких там настроек. Начиная от контекста пользователя и заканчивая форматом представления даты.
С точки зрения T2, всё происходит в ее личном соединении, потому что использовать тот факт, что в нём же работает T1, она не имеет права — иначе нарушается изоляция.
Поэтому хорошие библиотеки/фреймворки оформляют такие вещи в виде отдельного соединения. Если нижележащий провайдер умеет пулить соединения или даже гонять транзакции по тому же каналу параллельно — честь ему и хвала. Пусть себе делает это там, глубоко под палубой, в машинном отделении. Чтобы капитан, т.е. разработчик, не грел себе голову, что будет, если в процессе работы с T2 вложенный код "починит" текущее значение ANSI_NULLS для соединения, и забудет его вернуть обратно.

A>>> А Вам скольких способов хватает?
IB>>Достаточно одного.
A>Всем доподлинно известно что любую задачу можно решить минимум 2-3 способами. Причем методики решения могут кардинально отличаться, и все будут давать правильные результаты. Именно поэтому я не могу никогда сказать, что я нашел все доступные способы решения задачи. Ну приучили меня к этому, и это мировоззрение я считаю верным, т.к. человек не бог, и я не бог. Я не могу увидеть все решения задачи, хотя вижу их по 2-3 практически всегда, а частенько и больше. Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.
Э-эх. Опять классика кун-фу. Очень хорошо, что ты видишь 2-3 решения там, где новичок с трудом находит одно. Но это далеко не последний дан. Предрекаю тебе чувство глубокого отчаяния, которое охватит тебя через годы при попытках объяснить новичкам, почему нельзя делать некоторые вещи, даже если кажется, что они приводят к тому же результату. И ты точно так же будешь говорить "это темная сторона силы", а они будут говорить "нет учитель, есть разные способы".

... << RSDN@Home 1.2.0 alpha rev. 677>>

mmaxx однажды (19 сентября 2007 [Среда] 12:45) писал:

> Знаю, что тема не нова, но время не стоит на месте...

Я в свое время ушел...
postgresql наше все!

--
...belive in the matrix...

Posted via RSDN NNTP Server 2.1 beta

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, 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 благодарить незачто.

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

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

AC>>А может ты сперва ознакомишься с тем, что там и как в IB/FB, прежде тем строить эфемерные теории?..
IB>Можно ссылочку на документацию FB, где сказано, что он выполняет мини откаты при RC, и как он это делает?

Иван, IB/FB никогда ничего "втихаря" не делает.
А речь свою веду о том, что ты не знаешь,
какие "подуровни" RC существуют у IB/FB, но при этом
заявляешь, что Oracle поступает правильнеееее

PS: Документация у Кузьменко на сайте (ibase.ru)
PPS: Умиляет твоя безапелляционность.

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

SM>Твои ответы уводят в сторону.
Я не виноват, что ты их не читаешь...

SM>Так как в них нет ни одного аргумента в пользу того, что моё утверждение не верно.
Вних аргументов более чем достаточно.

SM> — ACID для клиента ни к месту. Не будем же мы в самом деле забирать хлеб у сервера.
Тот же вопрос. Ты правда считаешь, что если ACID нарушится на клиенте, то перевод базы из одного состояния в другое станет более согласованным?

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

SM> Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!

Для тупых похоже не получается.

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

AC>>PS: Документация у Кузьменко на сайте (ibase.ru)
IB>Так конкретной ссылки не будет? Я вообщем-то так и думал.

А как Коваленко за марсом на мсдн посылать, так это с удовольствием?

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

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

КД>А, даже в голову не приходит?
Не, обычно не приходит.

КД>И ты значит отвечаешь за всех программистов "нормальных" серверов? Ты их всех знаешь по-именно?
Программисты нормальных серверов не отстаивают священное право, н апрострел собственных ног с таким упорством.

КД>Иван, это тупик рассуждения...
Я рад, что ты это понимаешь..

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

AC>>>Иван, IB/FB никогда ничего "втихаря" не делает.
IB>>Кто-то говорил, что FB что-то делает в тихаря?
AC>И снова передёргиваем. Браво.

Мужик — ты о чем?

AC>Не-а, не чувствую.
Ну тогда и говориь не о чем.

AC>У Oracle строже по сравнению с чем?
По сравнению с реализацией в FB.

AC>А зайти на сайт не пробовал?

Так где конкретная ссылка?

AC>Попрошу не возводить на меня напраслину!
По делу тобой не было сказано ничего. При попытке коснуться технических вопросов — несешь полную чушь.

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

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

IB>О чем я собственно и говорил. В FB миниоткатов нет. Хотя кое-кто пытался весьма неуклюже обвинить в обратном...

что такое "миниоткаты" — это новый термин? или это внутренний savepoint, который ЕСТЬ в IB/FB?

КДВ>> RC в ней можно сравнить хотя бы с RC реализуемом в версионности в MS SQL 2005,
КДВ>>к Ораклу переходить необязательно.
IB>К ораклу перешел не я. Было утверждение, что в FB RC накой же как в оракле. Так вот это не так, RC в оракле отличается от FB-шного.
IB>Будешь спорить?

не буду. я хочу аргументации, со ссылкой.

КДВ>>но Вам бы я посоветовал всю серию по версионности почитать, для начала
IB>Я бе тебе советовал не спорить со мной про версионность.

да ну? или версионность в MS SQL уже 23 года? Или Вы (ты) работаете(шь) с
версионным сервером лет 12 ?

КДВ>> Речь, как я понимаю, об атомарности оператора select?
IB>Речь о различных реализациях уровня RC.

В ЧЕМ ОНА ОТЛИЧАЕТСЯ. Прошу сообщить.

КДВ>>Зачем тут делать "микрооткаты", как и вообще "микрооткаты" непонятно чего, если Оракл "тоже версионник — неясно.
IB>Если не ясно, тогда не надо спорить.

то есть, я умом не вышел? Позвольте спросить, что это тогда за уровень беседы —
и "сервер у вас неправильный, и про микрооткаты ни в зуб ногой, и ссылок я не дам, и вообще, мне лениво".
Так? Напрягитесь, пожалуйста, хоть один вменяемый аргумент дать. Хотя бы про микрооткаты
или несоответствие RC. Трындеть любой новичок может. Я Вам уже кучу ссылок дал, а Вы все как-то
по нулям.

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

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

T>>Идеально было бы ещё запрстить сюда цтатау, однозначно подтверждающую твою правоту.

IB>Тебе не кажется, что было бы странно, если бы в стандарте было упомянуто, что "Tonal- ошибается в своей трактовке ACID".

Естественно в стандарте такого не указано, как не указано и то, что "IB вещяет истину в последней инстанции — верте ему!"

Моя просьба звучала несколько иначе (здесь:

T>>В таком случае, привиди ссылки на стандарты и документацию, которые подтверждают твоё утверждение.
T>>Устроют ссылки на стандарт SQL 2003 или на онлайн документацию по любому серверу. С точностью до абзаца.

Если непонятно, какие именно твои утверждения я просил обосновать, то эти (здесь и здесь):

T>>Мне всегда казалось, что ACID — это гарантии именно сервера относительно данных.
T>>И пока клиент не лезет в "нутро" сервера, а пользуется педоставленными ему интерфейсами, он может расчитывать на их выполнение.
T>>А если пользуясь только стандартными средствами клиент может в лёгкую нарушить эти гарантии сервера, то стало быть и нет никаких гарантий.
IB>Ты ошибался

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

T>>По твоим словам выходит, что любая программа, которая хоть как-то использует данные вне транзакции нарушает эти самые мифические гарантии.
IB>Во-первых, я ни слова не говорил про гарантии вообще и гарантии сервера в частности, а во-вторых, из моих слов совсем не следует что любое использование данных нарушает ACID.
Именно следует, и именно из твоих слов.
Но в принципе, я могу заблуждаться — по приведённым ссылкам я думаю это будет ясно видно.

... << RSDN@Home 1.2.0 alpha rev. 763>>

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

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

T>>Моя просьба звучала несколько иначе (здесь):
IB>Твоя просьба звучала именно так.
Хорошо, значит это ты не можешь аргументировать. Ок.

Можешь ли ты, привести ссылки на конкретные страницы/абзацы документации по любому серверу, где говорится о том, какое именно поведение клиента нарушает ACID гарантии сервера (здесь и здесь)?

T>>Мне кажется, что если человек требует привести примые ссылки сыоих от своих оппонентов
IB>Ты ошибаешься.. )
В том что ты не можешь привести не одной ссылки?
Или в том что ты некомпетентен в обсуждаемом вопросе?

T>>Именно следует, и именно из твоих слов.
IB>Ты не правильно трактуешь мои слова. Думаю сначала следует научиться читать.
Значит, тебе следует научится выражатся яснее.

Хотя, похоже ты не очень понимаешь, что именно хочешь выразить.

IB>Впринципе это видно и без ссылок.
В общем-то да.

... << RSDN@Home 1.2.0 alpha rev. 763>>

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

AC>>Кем?
S>Чувством самосохранения и здравым смыслом.
AC>>В указанных статьях ни слова о запретах.

S>Гм. Есть такая штука, как логика.

И снова слив! Восхитительно.

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

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

___>Редкостное угробище. Только чего мне стоили его глюки с инлайнингом

Правда? Ой, а я и не знал

Спасибо! Вы открыли мне глаза

Если хочешь поговорить о багах этого семейства компиляторов, о багах и проблемах VC — давай это сделаем в другой ветке. Думаю, это было бы забавно собрать в одном месте все мои сообщений по этой теме, которые я публиковал на форуме C++. Может кто еще что напишет полезное.

Уверяю у меня уже давно нет никаких "слабостей" ни к BCB, ни к VC. Как впрочем и к FB, тоже. Просто эксплуатирую в корыстных целях.

А рассказать есть о чем. Без воплей "О как я с ним трахался!", а с конкретным примерами. Траблы с инлайнингом проскакивали когда я в get-property юзались инлайновые get-функции, возвращающие сложные объекты типа std::string. Забавно, но прямой вызов этих функций без всяких там __property проблем не вызывал. Это не самое страшное — причину одной проблемой я несколько лет не мог осознать. Потом понял без всяких там отдачиков и т.д. Я не про баги в ДНК разработчиков этого компилятора. Про другое

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

AC>Иван,
Нда. Вот уж не думал, что меня с "этим" перепутают, зачем людей-то по себе судить?... (
Обычно я для ахинеи использую другой ник, но Alex.Che уже к сожалению знаят, приходится воздерживаться...

AC>ты сперва почитай таки доку, ссылку на которую тебе дали, а потом приходи, будем обсуждать нюансы
AC>IL RC в FB, и его отличия от Oracle с его "миниоткатами". До тех пор, пока не прочитаешь
Если имеется ввиду ссылочка на Critique of ANSI SQL isolation levels, то вот лично я (IB, Merle) ее читал еще в 99-м или 98. Самое забавное в том, что первый русский перевод этой классичской статьи (который был опубликован на osp) был настолько крив, что полностью искажал смысл. В вашу версию перевода я даже не заглядывал, но будьте аккуратнее, прочитайте все-таки оригинал..

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

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

КДВ>> Почему там нельзя одновременно стартовать две, три, 5000 транзакций???
IB>Для того чтобы это делать надо на клиенте заниматься изнурительным многопоточным программированием, разруливая одно соедиение между несколькими потоками. Гораздо проще и надежнее не делать этого.

Вы меня извините, но это нонсенс. где тут изнурительное программирование?
...
TR1.StartTransaction;
...
TR2.StartTransaction;
...
TR1.Commit;
TR2.Rollback;

В IB/FB нет управления транзакциями в SQL. Транзакциями управляет только клиент. Никакого "изнурения" тут нет,
и тем более "многопоточное программирование" не требуется, и "разруливать" ничего не надо.
Вы в понятие "параллельность" сразу вкладываете "многопоточность". Здесь же имеется в виду
что в одном соединении можно стартовать N транзакций одновременно.

КДВ>> Где здесь и что нелогично?
IB>Я уже устал объяснять что.

аналогично.

КДВ>>почему "шарить"? шарить между кем?
IB>Между тем, кто собрался создавать параллельные транзакции, они же не из воздуха берутся.

см. выше.

КДВ>>Их просто можно стартовать одновременно в контексте одного коннекта. Это очень удобно.
IB>Это не удобно. Удобно, это когда ты не думаешь открыто у тебя соединение или нет и не ищещь глобальный объект, где у тебя это соединение лежит, а тупо берешь и создаешь, когда оно тебе понадобилось.

Это Вам неудобно. Нам — очень даже удобно.

КДВ>>это никак не усложняет написание приложений.
IB>Ты даже не представляешь, как это усложняет написание.

Я много себе чего представляю. В том числе что усложняет и что нет.
Если по подписи непонятно, то я это "Кузьменко Дмитрий Валерьевич", ibase.ru,
который работает с IB с 1994 года.

КДВ>> И на мой взгляд пулинг тут вообще ни при чем.
IB>Пора расширять кругозор..

пора и Вам аналогично, расширить.

КДВ>>Допустим, ваш клиент будет открывать новый коннект на новую транзакцию автоматически.
IB>Ты точно хорошо себе представляешь, как все на самом деле работает?

Абсолютно точно. См. выше.

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

M>Может, насоветуете альтернативную СУБД:
M>* бесплатная;
M>* параллельные транзакции;
M>* хранимые процедуры, триггеры;
M>* защита от юзверя (что раздражает в Firebird — так это божественное всемогущие SYSDBA).

M>Работать будет на клиентской машине, объем данных небольший, сотни Мб. Желательно embedded.
M>Ну и чтоб Data Provider для .NET был достойный

SQL Server 2005 Express

... << RSDN@Home 1.2.0 alpha rev. 746>>

SmlMouse пишет:
> kuj>SQL Server 2005 Express
> Параллельные транзакции?

Это что-то в Firebird перемутили. Транзакции параллельными и
перпендикулярными быть не могут.

> Embeded?

Нет.

> А поподробней, где почитать про всё это применительно к MS SQL?

BooksOnLine. Скачать мождно с сайта мелкомягких.

ЗЫ. Бесплатные версии есть также у Оракла и ДБ2. Все не embedded.
Смотрите что вам лучше,

Posted via RSDN NNTP Server 2.1 beta

Alex.Che пишет:
> Да что ты?! Да как же так?! Как же жить после этого?..

Можешь повеситься.

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

Posted via RSDN NNTP Server 2.1 beta

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

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

Честно-честно?
А пацаны то незнают:
Многоверсионность данных и управление параллельными транзакциями

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

M>>>Может, насоветуете альтернативную СУБД:
M>>>* параллельные транзакции;
M>>>Работать будет на клиентской машине, объем данных небольший, сотни Мб. Желательно embedded.
M>>>Ну и чтоб Data Provider для .NET был достойный

kuj>>SQL Server 2005 Express
SM>Параллельные транзакции?
MARS http://msdn2.microsoft.com/en-us/library/ms345109.aspx

SM>Embeded?
Не совсем, но можно цеплять файл базы по AttachDbFilename, не ограничиваясь при этом "встроенностью базы". Кроме того, по-умолчанию SQL Express ставится с локальной-only видимостью.
Это лучше, чем просто embeded для больших проектов.

SM>А поподробней, где почитать про всё это применительно к MS SQL?
MSDN

... << RSDN@Home 1.2.0 alpha rev. 746>>

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

kuj>>>SQL Server 2005 Express
SM>>Параллельные транзакции?
kuj>MARS http://msdn2.microsoft.com/en-us/library/ms345109.aspx

[Предельно вежливо] MARS предназначен для параллельной выборки из нескольких множеств в рамках одного подключения. А для MSSQL, соответственно — одной транзакции. Не более и не менее.

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

КД>>>Хорошо, явно (то есть не косвенно) две транзакции в MSSQL 2005 создать можно?
IB>>Можно.
КД>Слушай, вы как нибудь с kuj определитесь
КД>

КД>Though SQL Server 2005 does not support multiple active transactions per connection, the programming model already accommodates such a future enhancement

КД>Этот программинг модель у них существует с 98 года. Называется OLEDB

Может хватит уже своей некомпетентностью сверкать тут, Дмитрий? Может хватит спорить о том, о чем представления не имеете?
Вас уже два раза носом ткнули, разжевали и в рот положили, а Вы продолжаете с упорством фанатика доказывать, что Земля плоская и покоится на спинах трех китов...

Цитирую все из того же источника:

-----

MARS-enabled client drivers are the following:

* The SQLODBC driver included in the SQL Native Client.
* The SQLOLEDB driver included in the SQL Native Client.
* The SqlClient .NET Data Provider included in the Microsoft .NET Framework, Version 2.0.

-----

... << RSDN@Home 1.2.0 alpha rev. 746>>

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

КДВ> Почему там нельзя одновременно стартовать две, три, 5000 транзакций???
Для того чтобы это делать надо на клиенте заниматься изнурительным многопоточным программированием, разруливая одно соедиение между несколькими потоками. Гораздо проще и надежнее не делать этого.

КДВ> Где здесь и что нелогично?
Я уже устал объяснять что.

КДВ>почему "шарить"? шарить между кем?
Между тем, кто собрался создавать параллельные транзакции, они же не из воздуха берутся.

КДВ>Их просто можно стартовать одновременно в контексте одного коннекта. Это очень удобно.
Это не удобно. Удобно, это когда ты не думаешь открыто у тебя соединение или нет и не ищещь глобальный объект, где у тебя это соединение лежит, а тупо берешь и создаешь, когда оно тебе понадобилось.

КДВ>это никак не усложняет написание приложений.
Ты даже не представляешь, как это усложняет написание.

КДВ>Зачем для этого коннекты плодить, и думать про контекст?
Вот когда на транзакцию по соединению — все просто, никакой контекст тебя не чешет ни в одном месте. А вот когда соединение одно на несколько потоков, вот тогда и напляшешься в присядку.

КДВ> И на мой взгляд пулинг тут вообще ни при чем.
Пора расширять кругозор..

КДВ>Допустим, ваш клиент будет открывать новый коннект на новую транзакцию автоматически.
Ты точно хорошо себе представляешь, как все на самом деле работает?

КДВ>Ей-богу, ну не было раньше версионности в MS SQL. А сейчас есть.
Ну так и блокировочный движок не убрали, а наоборот, только развивают.

КДВ>Будут и "параллельные транзакции"

Да они уже есть, а толку?

КДВ>Но я же не говорю, что это совсем не нужно, и не имеет смысла.
Зато ты говоришь, что транзакция на подключение смысла не имеет, в чем глубоко заблуждаешься.

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

AC>И снова ты судишь со своей колоколни...
Естественно, это же моя колокольня.

AC>Кто мешает держать активной одну долгоиграющую транзакцию
Зачем? Можешь мне придумать сценарий когда это надо?
Неговоря уже о том что сам факт "долгоиграющей" транзакции говорит о том, что что-то там не так напроектировали.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Привет, IB!
Вы пишешь 20 сентября 2007:

[Sorry, skipped]
AC>> Кто мешает держать активной одну долгоиграющую транзакцию
I> Зачем? Можешь мне придумать сценарий когда это надо?
I> Неговоря уже о том что сам факт "долгоиграющей" транзакции
I> говорит о том, что что-то там не так напроектировали.

Ну вот он, типичный штамп мышления человека привыкшего к блокировочнику...
Аналогичный вопрос: ты можешь показать, на пальцах, для тупых, чем это плохо?
(возвращаемся к тому давешнему флейму по поводу MGA)

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

Я вот только понять не могу зачем смотреть незакоммиченные данные из другой транзакции?

Пример:
1. Открывается подключение к базе данных Test и начинается транзакция. Уровень ее изоляции по умолчанию ReadCommitted
2. Открывается еще одно подключение и начинается еще одна транзакция. Уровень ее изоляции сделаем ReadUncommitted.
3. Из первой транзакции вставляется строка в таблицу Cat_Contr (контр агента добавили) коммит не делаем — может нам такой контр не нужен или это просто бухгалтер свои знания тестирует
4. Из второй транзакции выполняется чтение этой строки (Уровень изоляции позволяет читать незакоммиченные данные), далее их можно использовать дальше в других таблица. Но если первая транзакция сделает откат — целостность и согласованность данных можно потерять.

Если Вы хотите осложнять себе жизнь — пожалуйста

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

IB>У IB-шников похоже просто комплекс какой-то.

Стопудово

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

IZM>Я вот только понять не могу зачем смотреть незакоммиченные данные из другой транзакции?

IZM>Пример:
IZM>1. Открывается подключение к базе данных Test и начинается транзакция. Уровень ее изоляции по умолчанию ReadCommitted
IZM>2. Открывается еще одно подключение и начинается еще одна транзакция. Уровень ее изоляции сделаем ReadUncommitted.
IZM>3. Из первой транзакции вставляется строка в таблицу Cat_Contr (контр агента добавили) коммит не делаем — может нам такой контр не нужен или это просто бухгалтер свои знания тестирует
IZM>4. Из второй транзакции выполняется чтение этой строки (Уровень изоляции позволяет читать незакоммиченные данные), далее их можно использовать дальше в других таблица. Но если первая транзакция сделает откат — целостность и согласованность данных можно потерять.

IZM>Если Вы хотите осложнять себе жизнь — пожалуйста

Интересно — а кто себе жизнь осложняет с помощью ReadUncommitted? Если я правильно напряг свои мозги то такого в IB/FB просто нет. И никто не смотрит незакомиченные данные ни в одном примере. Выборка и фетч делаются по ЗАКОМИЧЕННЫМ данным, т.е. они есть в БД, а в каком состоянии стартует транзакция на выборку мне например глубоко по барабану (тем более что можно и в SNAPSHOT стартовать ее, если делать запись данных в другой транзакции).

Вообще почитал, и мне стало интересно — а те кто пишут про просмотр "незакомиченных" данных при обычном селекте хоть что-нибудь про транзакции IB/FB знают или нет? Похоже что нет.

Вопрос на засыпку — какие типы транзакций существуют в IB/FB. Кто из тех кто против IB/FB сможет ответить? Или просто не знаете?

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

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

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

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

IB>"(2) меняет данные на основании фетча из (1)" — означает, что (2) имеет доступ к незафиксированным данным из (1). Или есть какая-то другая, недоступная мне интерпретация данной фразы?

Простите за нескромный вопрос, вы знаете, что такое фетч? Если знаете, тогда объясните пожалуйста, какие в нем могут быть незафиксированные данные?

SM>> Так что пока я никак не могу увидеть, как транзакция (2) видит незафиксированные данные из (1).
IB>(2) видит данные из (1) в процессе работы (1) (до того как (1) зафиксировалась), это означает, что (2) видит незафиксированные данные (1) так как дать гарантию, что данные в (1) не менялись в процессе ее работы, никто не может.

Как так никто не может? А кто код программы, позвольте спросить, пишет? Генератор случайных чисел?

SM>> В транзакции (1) данные были зафетчены (забраны с сервера). Причем данные на состояние старта (1).
IB>Что мешает в момент старта (1) забрать данные с сервера и зафиксировать эту транзакцию, а потом начинать работать с (2)? Зачем держать транзакцию открытой, если по твоим же словам "commit/rolback (1) (не имеет значения, модификации не проводились)"?
IB>Что-то ты со своим примером сам запутался...

Кто же спорит, можно и так. Только почему вы позволяете себе утверждать, что если определенная задача в сервере X может быть решена способами A и B, а в сервере Y только способом B, то значит сервер X некошерный и способ A права на существование не имеет? Или разнообразие возможностей выполнения задачи с некоторого время является недостатком программы?

P.S. Только маленькая просьбочка... не нужно больше аргумента про "изнурительную многопоточность"... мы вчера полдня из под стола вылезти не в силах были, а нам работать надо...

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

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

R>Пытаемся задавить интеллехтом?

Напомню, форум по программированию, а не по толкованию философских принципов.

R>Вижу три критерия определения преимуществ:
R>- Наличие возможности.
Возможность не есть преимущество. Я потому и упомянул принцип бритвы оккама.

R>- Удобство использования.
Спорно. У нас в проектах, например, повсеместно используется NHibernate. Он сам заботится о корректной организации транзакций.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

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

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

A>>Вообще почитал, и мне стало интересно — а те кто пишут про просмотр "незакомиченных" данных при обычном селекте хоть что-нибудь про транзакции IB/FB знают или нет?
IB>Ты точно читал? все читал? внимательно-внимательно читал?

Очень-очень внимательно и весь пост.

IB>Еще раз, на пальцах, следи за руками:
IB>Транзакции изолированы, IB, как и все приличные серваки, всеми силами пытается недопустить чтобы сырые данные одной транзакции не увидела другая. Но народ собирается читать данные из одной транзакции на клиента и дать другой транзакции эти данные. На клиенте эти данные может поменять кто угодно и сервер это уже не отследит и вся изолированность "идет лесом" (с). Именно по этой причине так делать нельзя.

1. Сырые данные в IB/FB ты никак не прочитаешь. Если уверен что сможешь то RTFM по IB.
2. Есть идеальный мир и есть реальный. В реальном программисты работают для клиентов и им за это платят деньги. Т.е. любой программист должен работать и делать удобный интерфейс для клиента.
3. Задача в которой надо открывать 2 окна для работы с разными данными была описана (в одном отфетченный список клиентов например, в другом окне надо отредактировать какие-то данные про этого клиента)

Если следовать вашей логике, то надо закрыть список клиентов и потом открыть карточку клиентов в отдельном окне. Потом снова открыть список клиентов и продолжать работать. Клиенту использующему Вашу программу далеко по барабану как там внутри все работает, ему важно удобство. И IB/FB предлагает сделать это с минимальными затратами для программиста.

P.S. Может я немного утрировал сам процесс, но так более понятно думаю. Или есть варианты?

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

A>Очень-очень внимательно и весь пост.
Надо не пост читать, а ветку.

A>1. Сырые данные в IB/FB ты никак не прочитаешь. Если уверен что сможешь то RTFM по IB.
... нет слов. Сколько раз надо сказать, что речь не про FB и его уровни изоляции, а про то как эти уровни изоляции пытаются обойти на клиенте?

A>2. Есть идеальный мир и есть реальный. В реальном программисты работают для клиентов и им за это платят деньги. Т.е. любой программист должен работать и делать удобный интерфейс для клиента.
За интерфейсом для клиента — к UI дизайнерам, здесь же немного другой форум.

A>Клиенту использующему Вашу программу далеко по барабану как там внутри все работает,
Только при условии, что все работает без ошибок.

A> И IB/FB предлагает сделать это с минимальными затратами для программиста.
Ну да, а то перенапряжется — бедолага.

A>Или есть варианты?
Ты даже не представляешь сколько.

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

А>Абисняю. Все ОЧЕНЬ ПРОСТО.
А>Есть один TDatabase на приложение.
...
А>А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.

То есть, проблема в том, что борланд не смог написать правильную клиентскую библиотеку?

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

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

A>>Очень-очень внимательно и весь пост.
IB>Надо не пост читать, а ветку.
Сорь, описАлся.

A>>1. Сырые данные в IB/FB ты никак не прочитаешь. Если уверен что сможешь то RTFM по IB.
IB>... нет слов. Сколько раз надо сказать, что речь не про FB и его уровни изоляции, а про то как эти уровни изоляции пытаются обойти на клиенте?
Кто-то пользуется Вашим именем?
КДВ>в IB/FB транзакции реализованы в соответствии со стандартом и требованиями ACID.
IB> Нет, они не соответствуют стандарту, если уж на то пошло.

A>>2. Есть идеальный мир и есть реальный. В реальном программисты работают для клиентов и им за это платят деньги. Т.е. любой программист должен работать и делать удобный интерфейс для клиента.
IB>За интерфейсом для клиента — к UI дизайнерам, здесь же немного другой форум.
В данном конкретном случае UI пересекается с конкретной задачей.

A>>Клиенту использующему Вашу программу далеко по барабану как там внутри все работает,
IB>Только при условии, что все работает без ошибок.
Это по моему постулат, и передергивать совсем не надо не в ту сторону.

A>> И IB/FB предлагает сделать это с минимальными затратами для программиста.
IB>Ну да, а то перенапряжется — бедолага.
А в какую сторону у нас двигаются сейчас разработки? Что СУБД что языков программирования.

A>>Или есть варианты?
IB>Ты даже не представляешь сколько.
Вот именно что не представляю.

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

П>Иван, это передергивание.
Нет.

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

A>3. Задача в которой надо открывать 2 окна для работы с разными данными была описана (в одном отфетченный список клиентов например, в другом окне надо отредактировать какие-то данные про этого клиента)

в оракле поправить справочник можно в той же конекции в автонономной транзакции.

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

нормальная практика hibernate — кешировать справочники на апп-сервере

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

А>нормальная практика hibernate — кешировать справочники на апп-сервере

Кстати да, различные ORM с их "размазаным" временем жизни сущностей — еще один пример подобного подхода.

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

T>Мне всегда казалось, что ACID — это гарантии именно сервера относительно данных.
Ты ошибался.

T>Если рассмотреть твой ответ, то ни один снервер просто не в состоянии предоставить эти самые гарантии, что бы не написал разработчик.

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

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

A>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться?
Понятно — это клиника. Все что я мог сказать по этому поводу — я уже сказал.
Если непонятно, а очевидно непонятно, то значит моих объяснительных способностей недостаточно, в двадцать восьмой раз объяснять что я имел ввиду рассказывая про проблемы ACID в вашем подходе я не намерен.

A>Ну не совсем простую,
Она просто примитивна.

A> Все что я видел в посте, это голословные утверждения "Должно быть так и только так". Очень жаль.
Это говорит лишь о том, что ничего кроме этого ты увидеть там и не хотел.

A> Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.
Моего кругозора достаточно чтобы понять две простые вещи
1. На практике достаточно одного решения, главное чтобы оно работало в заданых граничных условиях.
2. Среди множества возможных решений, логически рассуждая, можно отсечь подмножество неверных, на разбирая каждое из них в подробностях.

A>P.S. И все-таки, VS? Вы на вопрос так и не ответили. Честно скажу — еще одну священную войну я заводить не собираюсь. Клянусь. Мне глубоко по барабану кто на чем пишет. Главное чтобы правильно.
Во-во, главное правильно.

Я потому и не ответил, что меня конечная платформа волнует в достаточно малой степени, я вообще архитектор, мне с чем только не приходится дело иметь.

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

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

P>А можно не открывать. Какая здесь необходимость в двух соединениях?

А какая необходимость в параллельных транзакциях? Это два никак не связанных, независимых действия.

P>Но самое приятное, что в ФБ я могу как открывать соединения, так и нет — я волен сам решать, что в данном, частном случаем, мне выгоднее(про, например, переменные сессии уже говорилось, причем не один раз....).

Ну приятно ездить на телеге с пятью колесами — на здоровье.
Но что получается? Пассажиры пятиколесной телеги:
— считают, что пятое колесо ну просто офигенное преимущество и технологически продвинутый ход;
— презирают остальных, кто ездит на четырехколесных;
— презирают создателей четырехколесных телег, называя их уродами, а созданый ими интерфейс — убогим;

Здравствуйте, <Аноним>, Вы писали:
А>А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.
Не надо ничего высчитывть. Вообще удерживать соединения открытыми — моветон. Во времена оны (когда BDE был бодр и весел) это считалось нормальным, но я напомню, что клиент-серверная архитектура (ныне заслуженно считаемая старомодной) тогда была только в проекте. ВDE с самого рождения проектировался для работы с безсерверными СУБД, и в первую очередь с Paradox (а во вторую — со всякими DBase). Интербейз был приклеен сбоку и значительно позже.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Andyshark, Вы писали:
A>Хм. А я где-то говорил что я СТОРОННИК BDE? Но я сторонник того что идея то была более-менее хорошая. Если бы она была совсем дерьмовая, то она бы уже давно умерла.
Факт, умерла.
A> Или вы считаете всех кто пользует BDE придурками и дерьмохлебами? Сразу скажу — я BDE уже сто лет не пользую, ну не сnоронник я ее в чистом виде. Но для своего времени это было очень даже и неплохо. Можете отделить идею от реализации? И учетом того КОГДА идея была сделана?
Могу. Идея — отвратительная. Да, в то время это было неочевидно. Еще вопросы?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, SmlMouse, Вы писали:
SM> Этот пример показывает, что ACID сервер нарушить не даст.
Ага.
SM> Я может быть не совсем правильный пример привел. Но его идея была в том, что бы не делая коммита T1 видеть изменения, привенесённые T2. И все в рамках одного коннекта из одного потока.
Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.

SM> Зачем это нужно — вопрос клиентского приложения.
Зачем — это вопрос философии. А мы находимся в СВ, т.е. еще дальше от практики. Технические детали велком в форум Базы Данных. А здесь мы обсуждаем вопросы веры отдельных товаришей в то, что некоторые порицаемые другими товарищами практики иногда могут иметь практический смысл.

SM>Для предметных областей было приведено как минимум два примера:
SM>1. Добавление клиента (T2) для изменяемого документа (T1)
Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.

SM>2. Ведение лога работы пользователя (работа в T1, лог в T2)
То же самое. Ведите лог через отдельное соединение. Чему это противоречит?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Если тут такие умные — можете подключиться к разработке сервера и продемонстрировать свою техническую подготовку в разработке супера третьей версии FB.
Ну, в свете присутствия линейки MS SQL мне догонять Редмонд лень

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Но тем неменее. В Редмонде работают реальные люди, как в прочем и в борланде, и в команде FB. И я, в силу своего характера, очень хорошо понимаю что географическое положение не влияет на мозги. И в связи с этим, в свое время на форуме OSP.RU "послал накуй" Сергея Кузнецова, который я так понимаю гуру российкого общества баз данных. А может его "однофамильца". Прошло восемь с лихом лет — я своего мнения, по этому вопросу, не поменял.
Не, ну давайте теперь меряться, кто кого послал и кто кому гуру.
Я вот лет восемь тому назад послал накуй Interbase 5.5 и 6.0 за неотчуждаемые родовые травмы головы, и своего мнения по этому вопросу не поменял. Потому что его писали люди, которые под СУБД понимали что-то другое, чем я. Возможно, с тех пор Interbase вышел из транса и научился хотя бы корректно выполнять простейшие запросы, но я к нему до сих пор отношусь с крайним подозрением. Я уважаю его умение работать во встраиваемом режиме, но в моих приложениях как раз это малосущественно.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

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

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

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

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

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

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

КД>> Если хочешь — могу обосрать ATL.OLEDB. Как ты догадываешься моей квалификации хватит за глаза.
IB>Только с точки зрения внутренней реализации. Но вот с точки зрения архитектуры клиентских приложений — лучше не надо..

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

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

AC>>Иван, IB/FB никогда ничего "втихаря" не делает.
IB>Кто-то говорил, что FB что-то делает в тихаря?

И снова передёргиваем. Браво.

AC>>А речь свою веду о том, что ты не знаешь, какие "подуровни" RC существуют у IB/FB,
AC>>но при этом заявляешь, что Oracle поступает правильнеееее

IB>Ты опять меня не читаешь? Или искажаешь намеренно?
IB>Я нигде не говорил, что Оракл поступает правильнее,
IB>я утверждаю, что у оракла RC строже. Чувствуешь разницу?

Не-а, не чувствую. Насморк у меня (пардону просим).

У Oracle строже по сравнению с чем?
С твоими теориями относительно IB/FB?

AC>>PS: Документация у Кузьменко на сайте (ibase.ru)
IB>Так конкретной ссылки не будет? Я вообщем-то так и думал.

А зайти на сайт не пробовал?

Там вверху большими буковками написано ДОКУМЕНТАЦИЯ

AC>>PPS: Умиляет твоя безапелляционность.
IB>Меня умиляет ваша безграмотность и наивный троллизм.

Проверено спеллчекером. Ошибок не обнаружено.
Попрошу не возводить на меня напраслину!

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

SM>> Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!

IB>Для тупых похоже не получается.

Кругом одни тупые, ну что ты будешь делать...

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

SM>> — Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных.
IB>Сервер не даст, а вот на клиенте обойти это можно запросто — чем вы и занимаетесь...

Иван, а через два подключения значит этим заниматься низя...?

А, даже в голову не приходит?

И ты значит отвечаешь за всех программистов "нормальных" серверов? Ты их всех знаешь по-именно?

А все пользователи FB/IB в обязательном порядке делают это?

Иван, это тупик рассуждения...

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

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

SM>>Твои ответы уводят в сторону.
IB>Я не виноват, что ты их не читаешь...
Я их очень внимательно читаю

SM>>Так как в них нет ни одного аргумента в пользу того, что моё утверждение не верно.
IB>Вних аргументов более чем достаточно.
Аргуметов, показывающих, что подход one-connection:many-transactions хуже one-connection:one-transaction я не вижу.
Как внимательно не читаю — не вижу

SM>> — ACID для клиента ни к месту. Не будем же мы в самом деле забирать хлеб у сервера.
IB>Тот же вопрос. Ты правда считаешь, что если ACID нарушится на клиенте, то перевод базы из одного состояния в другое станет более согласованным?
Ты правда считаешь, что такая ситуация в рамках моего примера не возможна в модели one-connection:one-transaction?
Ещё раз. Серверу-серверово. Клиенту — клиентово. Реализовывать логику сервера на клиенте задача лишняя и неблагодарная.

SM>> — Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных.
IB>Сервер не даст, а вот на клиенте обойти это можно запросто — чем вы и занимаетесь...

SM>> Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!

IB>Для тупых похоже не получается.
Значит, сказать нечего.
Жаль

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

M>Знаю, что тема не нова, но время не стоит на месте...

M>Может, насоветуете альтернативную СУБД:
M>* бесплатная;
M>* параллельные транзакции;
M>* хранимые процедуры, триггеры;
M>* защита от юзверя (что раздражает в Firebird — так это божественное всемогущие SYSDBA).

M>Работать будет на клиентской машине, объем данных небольший, сотни Мб. Желательно embedded.
M>Ну и чтоб Data Provider для .NET был достойный

Мда. Я вот решил перечитать. Начальное сообщение.

Короче парень, выпей йайду и убей себя об стену. Тебе никто не поможет.

Думаю одна из причин в том что у ADO.NET нет интерфейса для поддержки "параллельных" транзакций. То есть типа это два противоречивых требования.

Но если религия не мешает, можно соорудить свой .NET движок к серверу, который поддерживает несколько транзакций в одном подключении. Полагаю на роль последнего подходит только семейство IB-серверов

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

SM> Если я добавлю, что tr1 стартанута в режиме RC, вы останетесь на своем мнении?

Да.
Более того я предвидел то что ты начнешь говорить про уровни изоляции.

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

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

SM>В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку):
Написали уже — T2 пользуется данными T1, в тото моментпока T1 не зафиксирована.

SM>Этот агрумент говорит только о зрении смотрящего.
О! Запомни это. Отсюда я смело делаю вывод, что с вашим зрением что-то не то.

SM>Что изменилось с тех времён?

Ничего.

SM>И раз уж ты говоришь, что утверждение не логично, то принято приводить доказательство.
Не мужик. Это ты сказал, что это утверждение логично — вот и приводи доказательство, почему оно логично.

SM>Ну и заодно, вдруг не знаешь:
Да, и вот это тоже почитай..

SM>Это нужно понимать как "ситауция возможна в обоих случаях"
Именно.

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

T>Моя просьба звучала несколько иначе (здесь:
Твоя просьба звучала именно так.

T>Мне кажется, что если человек требует привести примые ссылки сыоих от своих оппонентов
Ты ошибаешься.. )

T>Именно следует, и именно из твоих слов.
Ты не правильно трактуешь мои слова. Думаю сначала следует научиться читать.

T>Но в принципе, я могу заблуждаться — по приведённым ссылкам я думаю это будет ясно видно.

Впринципе это видно и без ссылок.

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

SM> Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()

Не пропустил, так как в коде есть строчка update table1 set field2=updated where field1 = 1, где 1 — незафиксированные данные первой транзакции.

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

A>Ты наверное не догнал,
не догнал. Уж очень задача экзотическая.
A> но записи надо печатать по одной или более, на одном или более принтерах, причем сбойнуть может любой принтер в любой момент, а остальные должны продолжать печатать. Т.е. если я работаю в одной транзакции то должен после каждой делать коммит вместо того чтобы в данном случае просто сделать откат обновляющей транзакции? Я правильно понимаю?
Конечно. Я не понимаю, каким образом тебе поможет откат обновляющей транзакции.

S>>А чем вам поможет snapshot транзакция? Покажите мне, что делается в первой транзакции, и что во второй.
A>1. select bla-bla-bla from table
A>2. delete from table where id=:id
И почему это делается в разных транзакциях, а не в одной?
A>С таблицей однозначно делаются только операции вставки и удаления. Причем некоторые записи должны быть напечатаны в одном пакете, и если произошла хоть одна ошибка при печати то откатить весь пакет и соответственно пропечатать отмену печати при необходимости.
То, что печатается пакетом, делается в одной транзакции.
A>Первая читающая транзакция, можно сделать так что нагрузка сервера будем минимальна изначально (кстати, про такое Вы наверное не знаете?).
Может, и не знаю. Пока что я вообще не могу понять, чего хочется получить.
A>Вторая чисто под удаления запускается. В чем порочен данный метод? Или мне надо делать два коннекта?
Удобнее всего делать столько коннектов, сколько принтеров.
A>Если нет, то лучше нагружать сервер откатами транзакций и иже с ним?
Откаты транзакций существуют независимо от нашего сознания. Если есть необходимость откатить изменения — она произойдет, и стоимость ее слабо зависит от того, в каком количестве транзакций ну
A>P.S. Можно конечно запускать запросы по одному, но по мне это достаточно геморный вариант. Хотя Вам виднее. Я был бы раз если мне предложат более простой способ для решения этой задачи.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

SM>> Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()

IB>Не пропустил, так как в коде есть строчка update table1 set field2=updated where field1 = 1, где 1 — незафиксированные данные первой транзакции.
Ясно. В tr1 данные где-то меняются? Или всё-таки значение 1 существовало до момента старта tr1?
Если существовало, то где tr2 видит незафиксированные (читай некоммиченые) данные tr1 ?

P.S. У меня всё больше создаётся впечатление, что обсуждение закончилось, и начался низкопробный стёб.
Потому что если не стёб, то такого отрыва от реальности я давненько не видел...

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

пример поскипан, ибо будем разираться по порядку. Когда закончим с моим, вернёмся к твоему.

WH>>>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний.
SM>> Вот так. ANSI стандарт уже нам не нужен?

S>При чем здесь ANSI стандарт? Есть жесткая математика, которая описывает что такое сериализуемость транзакций.
S>Есть еще более жесткая реальность, в которой гарантированное обеспечение этой сериализуемости обходится очень дорого.
S>К примеру, любой селект должен приводить к блокировке не только отфетченных данных, но и предиката, причем блокировка должна удерживаться до конца транзакции.
Блокировка — это к MS SQL.
Мы сейчас обсуждаем поведение двух транзакций безприменительно к конкретному серверу.

S> Поэтому разработчики СУБД придумали такую штуку, как "уровни изоляции". Уровень изоляции вовсе не означает "ослабленной изоляции", как может показаться наивным детям. Уровень изоляции — это договоренность о том, чего нельзя делать во время такой транзакции, чтобы сериализуемость по прежнему обеспечивалась.
Вообще, придумали не разработчики конкретной СУБД, а целое сообщество людей. И отразили свои придумки в документе под названием
ANSI/ISO SQL Standard.

WH>>>Если ты сознательно нарушаешь соглашения, то ты сам себе злобный Буратино.
SM>> Какие именно? Если можно, опишите подробно, где и что я нарушил?
S>Соглашения достаточно внятно описаны в уровнях изоляции. К примеру, в RC нельзя читать повторно те же данные. Иначе упорядоченность нарушится.
Это где это такое написано? Можно мне почитать?
Я хочу: внятную ссылку с точностью до обзаца.

SM>> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
S>Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными.
Почему? Почему я _ВСЕГДА_ ею должен пользоваться?
Можно увидеть что-то кроме голословных утверждений?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

AC>>>>Иван, IB/FB никогда ничего "втихаря" не делает.
IB>>>Кто-то говорил, что FB что-то делает в тихаря?
AC>>И снова передёргиваем. Браво.

IB>Мужик — ты о чем?

Вань, мужики в поле пашут.
Ко мне же, можешь обращаться просто — товарищ.
Напоминаю, речь идёт о твоих инсинуациях на тему:
=========Beginning of the citation==============
IB>Оракл, в отличии от FB, при обнаружении того,
IB>что данные менялись с момента начала запроса,
IB>выполняет миниоткат и перезапуск запроса
=========The end of the citation================

AC>>Не-а, не чувствую.
IB>Ну тогда и говориь не о чем.

И с юмором у тебя тоже напряг...

AC>>У Oracle строже по сравнению с чем?
IB>По сравнению с реализацией в FB.

А как там у FB? А, Иван?
Расскажи нам. Как там не так?
А то всё фантазии какие-то, полунамёки...
=========Beginning of the citation==============
IB>Таким образом RC запросы в Оракле более согласованные.
=========The end of the citation================

AC>>А зайти на сайт не пробовал?

IB>Так где конкретная ссылка?

Вот она.

AC>>Попрошу не возводить на меня напраслину!
IB>По делу тобой не было сказано ничего.
IB>При попытке коснуться технических вопросов — несешь полную чушь.

Прекрасный перевод стрелок. Восхищен. Браво.

Всё ещё жду развернутого ответа, что ж там не так с RC у FB.
Изо всех сил...

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

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

SM>>В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку):
IB>Написали уже — T2 пользуется данными T1, в тото моментпока T1 не зафиксирована.
Да? Честно-честно? А если всё-таки немного подумать?
Данные существовали до старта T1

Итак, некомпетентность твою я уже увидел.

SM>>И раз уж ты говоришь, что утверждение не логично, то принято приводить доказательство.
IB>Не мужик. Это ты сказал, что это утверждение логично — вот и приводи доказательство, почему оно логично.
Уходим от твета?
Ну-ну. Возьми книжку и стань в угол.

SM>>Ну и заодно, вдруг не знаешь:
IB>Да, и вот это тоже почитай..
После тебя

SM>>Это нужно понимать как "ситауция возможна в обоих случаях"
IB>Именно.

Итак. Некомпетентность, перевод темы, уход от ответов.
Слив защитан

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

S>Наблюдаемые феномены нужно трактовать как запрещенные
S>в данном уровне изоляции действия.

Кем?
В указанных статьях ни слова о запретах.

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

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

SM>пример поскипан, ибо будем разираться по порядку. Когда закончим с моим, вернёмся к твоему.

WH>>>>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний.
SM>>> Вот так. ANSI стандарт уже нам не нужен?

S>>При чем здесь ANSI стандарт? Есть жесткая математика, которая описывает что такое сериализуемость транзакций.
S>>Есть еще более жесткая реальность, в которой гарантированное обеспечение этой сериализуемости обходится очень дорого.
S>>К примеру, любой селект должен приводить к блокировке не только отфетченных данных, но и предиката, причем блокировка должна удерживаться до конца транзакции.
SM> Блокировка — это к MS SQL.
SM> Мы сейчас обсуждаем поведение двух транзакций безприменительно к конкретному серверу.
Дело не в блокировке. Обеспечение полной сериализуемости в условиях ad-hoc запросов стоит дорого независимо от используемой архитектуры. Иначе бы никаких уровней изоляции не существовало бы.
SM> Вообще, придумали не разработчики конкретной СУБД, а целое сообщество людей. И отразили свои придумки в документе под названием
SM> ANSI/ISO SQL Standard.
Совершенно верно. Этот стандарт разработан производителями СУБД.

S>>Соглашения достаточно внятно описаны в уровнях изоляции. К примеру, в RC нельзя читать повторно те же данные. Иначе упорядоченность нарушится.
SM> Это где это такое написано? Можно мне почитать?
SM> Я хочу: внятную ссылку с точностью до обзаца.
Тут уже давали тонны ссылок. Фактически, сам стандарт при описании уровней изоляции указывает действия, приводящие к нарушениям сериализуемости. Трактовать это нужно так: если вы хотите получать сериализуемость, избегайте сценариев, описанных в соответствующем уровне изоляции. Вот статья, уточняющая ANSI 92 в этом смысле.

SM>>> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
S>>Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными.
SM> Почему? Почему я _ВСЕГДА_ ею должен пользоваться?
Ну почему же всегда? Ты должен ей пользоваться только в тех жалких 99% случаев, когда нарушение целостности данных может привести к убыткам.
SM> Можно увидеть что-то кроме голословных утверждений?
Цитируем http://emanual.ru/download/www.eManual.ru_538.html#part_4:

Феномен P1 может быть представлен как запрещение на следующую последовательность операций:

(2.1) w1[x]...r2[x]... (a1 и c2 в любом порядке)

(выделение моё).

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

IB>Сколько раз тебе надо сказать, что я ни слова не говорил про гарантии сервера?
IB>С сервером все в порядке. Вы нарушаете требования изолированности транзакции на клиенте.

Это что-то новое в теории RDBMS

А можно как-то формализовать сии требования?
Несомненно это будет прорыв.

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

kuj>Зачем Вы тратите свое время? Спорить с фанатиками firebird бесполезно. Для них FB это единственная правильная СУБД и точка.
kuj>Не пытайтесь их переубедить — только реалии жизни с этим справятся.

здесь нет фанатиков FB. Здесь есть люди, которые в основном используют FB, но при этом работали
с MS SQL, Oracle, PostgreSQL, MySQL и другими серверами. Я, например, вовсю попрограммировал
и на MUMPS (и еще знаком с Informix, правда в общих чертах, но ближе к администрированию).
Да, я не испытываю особой любви к блокировочной архитектуре. Но вполне четко могу определить,
какая задача будет легче решена на блокировочном сервере, а какая на версионном.
И нисколько не смущаясь, выбрать именно тот сервер, который лучше подойдет для решения задачи.

Именно поэтому меня (и нас "фанатиков FB"), удивляет ортодоксальность мнений оппонентов.
Основная суть этого спора, что "две транзакции в одном коннекте — плохо и неправильно".
И то же самое начали применять даже к "два коннекта в одном приложении — это плохо".
При том что Д. Коваленко написал, что в последних версиях драйверов от MS УЖЕ
предусматривается возможность старта двух и более транзакций одновременно в одном соединении.

Если подобная функциональность в FB вызывает неприятие, тогда давайте повернем вопрос
в плоскость вашего сервера — зачем MS расширяет собственную функциональность АНАЛОГИЧНЫМ способом?

Я напомню, что похожие баталии были по поводу версионности — типа, все это фигня и никуда
не годится. Оглянитесь вокруг — версионность нынче в Oracle, PostgreSQL, MySQL и даже MS SQL.
Аналогии с текущим спором не просматривается?

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

КД>>Мда. Я вот решил перечитать. Начальное сообщение.
КД>>Короче парень, выпей йайду и убей себя об стену.
КД>>Тебе никто не поможет.
КД>>Но если религия не мешает, можно ...
SM>Ни пойдёть.

Слушай я понял. Нам неправильно все объясняли. А мы не поняли где мы и с кем мы общались.

— Две транзакции в одном подключении нельзя, потому что с каждого подключения можно срубить бабло.

— Мы с тобой в магазине.

— Объясняли нам менеджеры по продажам. Ну ты же их знаешь. Они же никогда не скажут — возьмите один ящик с двумя тюнерами. Скажут — возьми два(три, четыре) ящика. Вы же запутаесь, а тут все конкретно — вот он ящик, вот конкретная передача.

Такие вот дела.

AC>А зачем?
AC>Когда Oracle с IBM меряются, оно понятно, речь идёт о рынке и баблосах.
AC>А для FreeWare это зачем?
AC>Повторяю, неофициальные тесты опубликованы. Выводы сделаны.

дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ... да и без поддержки smp ему там делать нечего. класик у которого даже кеша общего нет это не архитектура, а недорзумение.

по Isolation levels — оракл на read commited обеспечивает консистентный набор (если не считать баг/фичу с минирестартами), IB и его клоны на IL read commited обеспечивают кашу в наборе, точно такую же какую обеспечивают блокировочники (имхо от того что каша соответствует стандарту мало чего меняется), поэтому считается что read commited оракла несколько выше.
к стате в новом OLTP тесте TPC-E mssql уже приходится в версионном режиме гонять.

ЗЫ. на счет параллельных транзакций, постоянно юзаются в оракле: основная транзакция прежде чем выполнить действия регистрирует попытку действия в автономной транзакции (в том же конекте естественно) передая туда имя пользователя, код транзакции и прочую инфу из основной, после чего основная транзакция нарывается на какое-то исключение и благополучно откатывается, при этом попытка фиксируется автономной транзакцией. все происходит на сервере, естественно не нарушая никаких IL ... но доказать очевидное некоторым личностям вам не удастся

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

КДВ>и? статья-то о том, что
КДВ>а) данных уровней изолированности не хватает
КДВ>б) базовые уровни изолированности ориентированы на блокировочные сервера
КДВ>в) некоторые уровни изолированности описаны криво

КДВ>все это не говорит о том, что единственно возможный применимый в реальной жизни уровень
КДВ>изолированности транзакций — сериализация.
Вы путаете уровень изоляции и сериализуемость сценария.
КДВ>Да, я согласен, некоторые задачи
КДВ>решаются только сериализацией.
Что вы называете "сериализацией"?
КДВ>Например, у меня на курсах примерно в 98 году был
КДВ>мужик, который заявил:
КДВ>- зачем вы об уровнях изолированности рассказываете? у нас все четко — вагон
КДВ> пришел, попал под разгрузку, и ушел. Тут никаких конфликтов быть не может.
Не надо ему уподобляться.
КДВ>Но в реальной жизни сериализация — вовсе не обязательное условие, а даже очень частное.
Сериализация — это про превращение данных в поток байт. Сериализуемость — это четко математически определенное свойство последовательности операций. Читайте литературу, хотя бы ту же статью, за определением.
КДВ>Два человека могут читать одну книгу одновременно.
КДВ>несколько человек могут находиться в одном вагоне.
КДВ>несколько человек могут читать копию одной книги одновременно
КДВ>и так далее.
Математика совершенно однозначно говорит, какие сценарии можно представить в виде последовательности выполняющихся друг за другом транзакций, а какие — нельзя.
По-хорошему, работа СУБД состоит в том, чтобы запрещать все сценарии, кроме сериализуемых. Потому, что иначе могут возникнуть проблемы с целостностью данных.
Но точное выполнение этих запретов — достаточно дорогое удовольствие. Поэтому ввели такое понятие, как "уровень изоляции".
Его смысл сводится к тому, что если вы опустили уровень изоляции ниже, чем SERIALIZABLE, то СУБД запрещает не все аномальные сценарии, а только некоторые из них. Статья как раз описывает, какие сценарии запрещаются каким уровнем изоляции. Так вот, остальные аномальные сценарии придется запрещать вам, как разработчику. Уровень изоляции —
это способ сказать СУБД "не напрягайся, вот за этим я сам прослежу". В частности, если мы точно знаем, что в пределах транзакции происходит однократное чтение, то можно ее выполнять и на RC — сериализуемость не нарушится. Несмотря на более низкий уровень изоляции по сравнению с SERIALIZABLE. Это и есть ваш пример про книгу и вагон.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Gt_, Вы писали:
Gt_>вы тут совсем новенький что-ли ?

И это заявляет человек, первое сообщение которого датируется вчерашним днем

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AC>>Иван, и стоило создавать для этой ахинеии клона?

Gt_>я не пойму, это вы меня клоном Мерле пытаесь записать

Gt_>вы тут совсем новенький что-ли ?

Вань, не стыдно?
Хоть бы слова в предложениях переставлял...

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

___>Если речь о лицензировании SQL Server, то одна лицензия на на пользователя подразумевает неограниченное кол-во подключений этого пользователя. Так шта опять мимо.

почему-же мимо? обломились рубить бабло за коннект именно потому, что архитектура не позволяет
использовать один коннект. приходится открывать много, а значит с лимитированием по коннектам — облом.
Там где можно лимитировать коннекты — еще как лимитируют, и рубят бабло.

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

КДВ>ссылкой на документ, в котором написано про миниоткаты в RC в Оракле.
Например здесь:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:11504247549852

КДВ>я поискал на techdocs, ничего похожего не нашел.
Если я правильно помню, то в доках этого нет, заставили Кайта проговориться, так поведение-то сервера надо объяснять. В связи с тем, что реализация кривая, оракл тщательно обходит этоу особенность в своей документации (но это уже совсем оффтопик). Хотя зачем искать, когда это довольно просто проверяется.
Вообще разборки по оракловской реализации RC, только на этом форуме, отгремели еще года четыре назад.

КДВ>не знаю.
Ну а что тогда?

КДВ>Вы заявили, что Вы знаете версионность лучше меня.
Исключительно в ответ на попытки обвинииь меня в том, что я знаю ее хуже, равно как и другие способы работы планировщиков БД.

КДВ>IB/FB Вы не знаете, а следовательно никак не можете составить ПОЛНУЮ картину по реализации версионности в СУБД.
ПОЛНОЙ картины не знает никто. А дял того чтобы понять, что может, что не может и причем тут вообще версионность — достаточно нескольких не самых новых учебников и пары лет практики.

КДВ>Это муть голубая.
Не нравится — не ешь.

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

AC>Вань, мужики в поле пашут.
Ну вот и паши...

AC>Напоминаю, речь идёт о твоих инсинуациях на тему:
Это не инсинуации — это разжевывание элементарных вещей.

AC>А то всё фантазии какие-то, полунамёки...
Никаких полунамеков. Я все очень четко описал, как для самых маленьких. Оракл выполняет откат одного запроса, при изменении данных в предикате, а FB — нет.

AC>Вот она.
По этой ссылке нет упоминания о том, что FB выполняет откат зпроса при изменении данных в предикате в RC.
Следовательно, у Оракла RC согласованнее. Возражения есть?

Знаю, что тема не нова, но время не стоит на месте...

Может, насоветуете альтернативную СУБД:
* бесплатная;
* параллельные транзакции;
* хранимые процедуры, триггеры;
* защита от юзверя (что раздражает в Firebird — так это божественное всемогущие SYSDBA).

Работать будет на клиентской машине, объем данных небольший, сотни Мб. Желательно embedded.
Ну и чтоб Data Provider для .NET был достойный

23.09.07 14:38: Перенесено модератором из 'Базы данных' — IB

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

M>Знаю, что тема не нова, но время не стоит на месте...

Забавная мысль пришла в голову (потеснив, находящуюся там еду) — "а ты что нибуть сделал, что бы другое (отличное от времени) не стояло на месте?"

M>Может, насоветуете альтернативную СУБД:
M>* защита от юзверя (что раздражает в Firebird — так это божественное всемогущие SYSDBA).

Странно это как-то...

А надежность, значит, вообще не интересует.

КД>А надежность, значит, вообще не интересует.

Некоторые вещи подразумеваются по умолчанию

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

M>>Может, насоветуете альтернативную СУБД:
M>>* параллельные транзакции;
M>>Работать будет на клиентской машине, объем данных небольший, сотни Мб. Желательно embedded.
M>>Ну и чтоб Data Provider для .NET был достойный

kuj>SQL Server 2005 Express
Параллельные транзакции?
Embeded?

А поподробней, где почитать про всё это применительно к MS SQL?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

Привет, Ромашка!
Вы пишешь 19 сентября 2007:

Р> они будут просто разными.

Гы

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

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

>> kuj>SQL Server 2005 Express
>> Параллельные транзакции?
Р>Это что-то в Firebird перемутили. Транзакции параллельными и
Р>перпендикулярными быть не могут.
Ну, с исторической точки зрения FireBird тут совсем ни при чем.
"Перемутил" Джим в незапамятные времена.
За что многие люди (и я) ему благодарны.

>> Embeded?
Р>Нет.
Это было одно из требований.

>> А поподробней, где почитать про всё это применительно к MS SQL?
Р>BooksOnLine. Скачать мождно с сайта мелкомягких.
Там ни слова про параллельные транзакции.

Р>ЗЫ. Бесплатные версии есть также у Оракла и ДБ2. Все не embedded.
Не в одном из перечисленных нет того, что нужно:
— несколько транзакций на сессию. тем более с разными уровнями изоляции
— минимальные затраты на развёртывание (положил DLL в каталог продукта и все. Или еще проще — прилинковал либы в экзешник).
— открытые исходники с возможностью модификации.

Итого: к чему вообще был этот пост?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

КД> А для MSSQL, соответственно — одной транзакции. Не более и не менее.
Нет, транзакции разные.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

КД>> А для MSSQL, соответственно — одной транзакции. Не более и не менее.
IB>Нет, транзакции разные.

Иван, признаюсь честно — я не тестил это дело. Ни разу.

Но по-логике вещей: если я стартовал транзакцию (создал сессию), стартовал транзакцию, в рамках сессии (с активной транзакцией) открыл два множества, то откуда тут будет две транзакции?

Хотя ... если я работаю в "автокоммите" (то есть с автоматическим стартом транзакций), то возможно ... Ну да, точно. И, судя по твоей довольной улыбке, отдельные подключения для этих автономных транзакций значит не создаются?

Хорошо, явно (то есть не косвенно) две транзакции в MSSQL 2005 создать можно? Если можно, то я искренне за него порадуюсь.

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

Сорри, на всякий случай уточню

КД>Хорошо, явно (то есть не косвенно) две транзакции в рамках одного подключения в MSSQL 2005 создать можно? Если можно, то я искренне за него порадуюсь.

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

КД>Но по-логике вещей: если я стартовал транзакцию (создал сессию), стартовал транзакцию, в рамках сессии (с активной транзакцией) открыл два множества, то откуда тут будет две транзакции?
Ну, в этом случае, конечно, нет. А если явно открыть две транзакции и начать выгребать два множества, то запросто.

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

КД>Хорошо, явно (то есть не косвенно) две транзакции в MSSQL 2005 создать можно?
Можно.

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

КД>>Хорошо, явно (то есть не косвенно) две транзакции в MSSQL 2005 создать можно?
IB>Можно.
Слушай, вы как нибудь с kuj определитесь

Though SQL Server 2005 does not support multiple active transactions per connection, the programming model already accommodates such a future enhancement

Этот программинг модель у них существует с 98 года. Называется OLEDB

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

КДВ>все кстати, очень логично.
Хм.

КДВ> Есть коннект. в его рамках можно одновременно стартовать несколько транзакций.
Вот это уже не логично.

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

Р>Бесплатные версии есть также у Оракла и ДБ2. Все не embedded.
Р>Смотрите что вам лучше,

А кто-нибудь поделится впечатлениями работы с DB2 Express-C?

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

kuj>Может хватит уже своей некомпетентностью сверкать тут, Дмитрий? Может хватит спорить о том, о чем представления не имеете?

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

Что бы немного развить ваш уровень могу предложить посмотреть на OLEDB-свойство DBPROP_MULTIPLECONNECTIONS ("Multiple Connections"). Оно как раз и рулит поддержкой "несколько транзакций на одно подключение"

У OLEDB провайдера для 2000 сервера оно, по умолчанию, стоит равным TRUE
У 2005 — тоже TRUE

Когда TRUE — я могу создавать вторую сессию (объект управения транзакцией). В отдельнымом подключением.

Когда FALSE — говорит "объект уже открыт"

На обоих серверах. Что вообщем то очевидно

kuj>Вас уже два раза носом ткнули, разжевали и в рот положили, а Вы продолжаете с упорством фанатика доказывать, что Земля плоская и покоится на спинах трех китов...

Пока я вижу только Ваше весьма некорректное поведение. И Ваше упорное отождествление "технологии MARS" с поддержкой нескольких транзакций в рамках одного подключения. А это не одно и тоже. Точнее совсем две разных вещи.

Из Книги "Ado.Net 2.0 для Профессионалов" Сахил Малек (07.2006г)

/////
Глава 11/ Транзакции/ MARS
Mars — это новая технология, появившаяся в SQL Server 2005, которая позволяет одновременно поддерживать для одного подключения несколько активных наборов результатов.
.....
Однако MArs не выполняет команды паралельно. Они выполняются поочередно, а одновременно активными являются только наборы результатов.
...
Технология Mars позволяет запускать несколько чередующихся команд и поддерживать паралельные наборы результатов, но не позволяет выполнить одновременно несколько транзакций по одному подключению.
--------
Однако важно заметить, что в течении долгого времени OldeDb вел себя нападобие MARS. Но с одним существенным отличием.
Предыдущие версии OleDb делали вид, что поддерживают паралельную выборку наборов результатов по одному подключению, но в действительности они использовали скрытые подключения.
/////

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

IZM>Из Книги "Ado.Net 2.0 для Профессионалов" Сахил Малек (07.2006г)

IZM>/////
IZM>Глава 11/ Транзакции/ MARS
IZM>Однако важно заметить, что в течении долгого времени OldeDb вел себя нападобие MARS. Но с одним существенным отличием.
IZM>Предыдущие версии OleDb делали вид, что поддерживают паралельную выборку наборов результатов по одному подключению, но в действительности они использовали скрытые подключения.
IZM>/////

Это можно запретить

Скрытые подключения допускаются только в случае отсутствия явного управления траназкциями. Если программа самостоятельно управляет транзакциями, то при попытке выполнить второй запрос (при наличии открытого recordset от первого запроса) возможны два варианта
— ошибка с кодом DB_E_OBJECTOPEN
— принудительная закачка результатов первого запроса.

Хотя вот, если опираться на то, что для упрощения портирования кода MSSQL на IB/FB мне пришлось делать авто-коммит — явное управление транзакциями в MSSQL не очень приветствовалось. Так что, чуть что — автоматом создаем новое подключение. Поэтому и кричат налево направо — нам это не надо

... Кстати наверное это самая главная причина, по которой в OLEDB перед явным отключением от базы требуют предварительное освобождение всех дочерних объектов. Они же могут висеть с собственными коннектами.

Интересно, а открытые множества (в 2000-ом сервере) влияли в том числе и на возможность выполнения других запросов типа INSERT/UPDATE/DELETE ? То есть, если есть открытое множество — другие запросы этой транзакции в принципе невозможно выполнить?

Кстати, на один только OLEDB тут зря грешат. Тот же АDODB тоже весьма "помогает" — если от команды получен recordset и не закрыт, то последующие выполнения этой команды будут приводит к созданию новой низкоуровневой OLEDB-команды. Формально, все что нужно мог бы сделать сам провайдер, тем самым снизив затраты, которые у OLEDB-компонент относительно высоки — из-за сложности реализации их интерфейсов.

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

КДВ>> Есть коннект. в его рамках можно одновременно стартовать несколько транзакций.
IB>Вот это уже не логично.

коннект к серверу — это соединение с сервером. Чтобы в этом соединении
что-то делать. Почему там нельзя одновременно стартовать две, три,
5000 транзакций??? Где здесь и что нелогично?
К TDatabase можно прицепить 100 TQuery — это тоже нелогично?
А TTable? А логично, что в случае TTable по крайней мере раньше MS SQL
на каждый TTable открывал отдельное соединение?

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

почему "шарить"? шарить между кем? коннект — это сокет. чего хочешь туда и отправляй.
под "параллельными" транзакциями никто не имеет в виду что они параллельно лезут в сокет.
Их просто можно стартовать одновременно в контексте одного коннекта. Это очень удобно.

IB> А stateful приложения писать существенно сложнее чем stateless.

это никак не усложняет написание приложений. Бросил IBDatabase, прицепил к нему
например одну читающую транзакцию, а другую пишущую. И в читающей хоть обчитайся
круглые сутки. А пишущую завершай коммитом-роллбэком и рестартуй когда надо.
Зачем для этого коннекты плодить, и думать про контекст?

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

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

У меня такое ощущение что подобный спор где-то уже был.
Ей-богу, ну не было раньше версионности в MS SQL. А сейчас есть.
Будут и "параллельные транзакции"

p.s. я сам например терпеть не могу EXECUTE STATEMENT в InterBase/Firebird.
Но я же не говорю, что это совсем не нужно, и не имеет смысла.

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

КДВ>У меня такое ощущение что подобный спор где-то уже был.
КДВ>Ей-богу, ну не было раньше версионности в MS SQL. А сейчас есть.
КДВ>Будут и "параллельные транзакции"

Мда... но я думаю у нас будет что еще обсудить и сравнить. Например — триггеры

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

КД>Хотя вот, если опираться на то, что для упрощения портирования кода MSSQL на IB/FB мне пришлось делать авто-коммит — явное управление транзакциями в MSSQL не очень приветствовалось. Так что, чуть что — автоматом создаем новое подключение. Поэтому и кричат налево направо — нам это не надо

Либо с терминологией что-то не то, либо одно из двух...
Явное управление транзакциями — это явный begin tran/commit, чегож тут не приветствовать? Дальше есть два режима — implicit ON (не! явное) при фиксации или откате транзакции неявно создается новая транзакция и все последующие команды выполняются в ней. Второй implicit OFF — явные транзакции, для того чтобы объеденить операторы в одну транзакцию надо явно задать begin/commit, в противном случае каждый оператор выполняется в своей собственной транзакции. Вот не приветствуется как раз первый вариант.
Но причем тут подключения — не очень понятно.

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

КДВ>> Почему там нельзя одновременно стартовать две, три, 5000 транзакций???
IB>Для того чтобы это делать надо на клиенте заниматься изнурительным многопоточным программированием,

Не перегибай палку

КДВ>>почему "шарить"? шарить между кем?
IB>Между тем, кто собрался создавать параллельные транзакции, они же не из воздуха берутся.

А строку подключения к базе — ну не из воздуха же брать?

КДВ>>это никак не усложняет написание приложений.
IB>Ты даже не представляешь, как это усложняет написание.

Блин, я вот не могу понять — в чем именно проявлется усложнение?

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

Когда я это делал, я и знать не знал — что это так сложно

КДВ>>Зачем для этого коннекты плодить, и думать про контекст?
IB>Вот когда на транзакцию по соединению — все просто, никакой контекст тебя не чешет ни в одном месте. А вот когда соединение одно на несколько потоков, вот тогда и напляшешься в присядку.

IB, ни кто не заставляет обязательно делать многопоточное приложение. Но если вот понадобиться — а я сталкивался с тем что иногда просто надо, то вот как-то приятно без напрягов разделять одно подключение (да вообщем и транзакцию тоже) несколькими потоками. Поддержка многопоточного клиента — это забота уровня компонент доступа, а не сервера.

КДВ>>Допустим, ваш клиент будет открывать новый коннект на новую транзакцию автоматически.
IB>Ты точно хорошо себе представляешь, как все на самом деле работает?

И что же там делается?

КДВ>>Будут и "параллельные транзакции"

IB>Да они уже есть, а толку?

Я вот что-то снова не догнал. Мы тут ради интереса провели реальный эксперимент — я привел конкретные результаты. Тестили через OLEDB. Новая параллельная транзакция порождает НОВОЕ подключение

И на 2000 и на 2005

Ну проведи реальный эксперимент с другими компонентами. Напиши что нужно сделать. Дай тривиальный код в конце концов. Потому что это уже явно идет из пустого в порожнее.

КДВ>>Но я же не говорю, что это совсем не нужно, и не имеет смысла.
IB>Зато ты говоришь, что транзакция на подключение смысла не имеет, в чем глубоко заблуждаешься.

Ааааааааааа....

В FB/IB можно и зачастую так и делают — в каждый момент времени только одна транзакция. Можно и подключение создавать по требованию — никто не запрещает. Но практикующие ведущие собаководы иногда предлагают создавать по требованию именно транзакции. Понимаешь? И для этого семейства серверов — это норма. Которую не нужно моделировать через ... дополнительное соединение. Там есть такое понятие — дескриптор транзакции. "Активируется" при старте транзакции. Обнуляется при коммите/откате. Алес.

Кроме того, сейчас, на сколько я понимаю, с появлением временных таблиц действующих на уровне соединения, весьма актульно что бы "параллельные" транзакции действительно оставались в рамках одного подключения. Потому что иначе — новая "параллельная" транзакция просто не увидит эту таблицу.

И так далее и тому подобное.

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

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

КД>>Хотя вот, если опираться на то, что для упрощения портирования кода MSSQL на IB/FB мне пришлось делать авто-коммит — явное управление транзакциями в MSSQL не очень приветствовалось. Так что, чуть что — автоматом создаем новое подключение. Поэтому и кричат налево направо — нам это не надо

IB>Либо с терминологией что-то не то, либо одно из двух...
IB>Явное управление транзакциями — это явный begin tran/commit, чегож тут не приветствовать?

Я говорю про конкретный код, который переносили с MSSQL на FB. В период когда все ломились на бесплатные сервера. Переносил не я. Меня только попросили сделать автокоммит. Потому что в этом коде явных begin-ов/коммитов не было.

IB>Дальше есть два режима — implicit ON (не! явное) при фиксации или откате транзакции неявно создается новая транзакция и все последующие команды выполняются в ней. Второй implicit OFF — явные транзакции, для того чтобы объеденить операторы в одну транзакцию надо явно задать begin/commit, в противном случае каждый оператор выполняется в своей собственной транзакции. Вот не приветствуется как раз первый вариант.

Понятно. А есть возможность вообще запретить неявный старт?

IB>Но причем тут подключения — не очень понятно.

Да вообщем-то ни причем. Просто транзакции существуют не сами по себе, а в рамках подключения. А когда приложение явно не контролирует транзакции — вот тут то (как я понял) и приходят ... множества неявных подключений к базе данных. Хотя, конечно, без явного управления транзакциями это нужно еще умудриться породить много скрытых подключений.

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

IB>Это не удобно. Удобно, это когда ты не думаешь открыто у тебя соединение или нет и не ищещь глобальный объект, где у тебя это соединение лежит, а тупо берешь и создаешь, когда оно тебе понадобилось.

Кто мешает, если хочется, делать это в Firebird?

SmlMouse wrote:
> Честно-честно?
> А пацаны то незнают:
> Многоверсионность данных и управление параллельными транзакциями

Пацаны много чего не знают.

Posted via RSDN NNTP Server 2.1 beta

SmlMouse wrote:
> Р>Это что-то в Firebird перемутили. Транзакции параллельными и
> Р>перпендикулярными быть не могут.
> Ну, с исторической точки зрения FireBird тут совсем ни при чем.
> "Перемутил" Джим в незапамятные времена.
> За что многие люди (и я) ему благодарны.
Гм... Он не задумывался анд тем, что вы так извратите его идеи.

>> > Embeded?
> Р>Нет.
> Это было одно из требований.
Это было с грифом "желательно".
>> > А поподробней, где почитать про всё это применительно к MS SQL?
> Р>BooksOnLine. Скачать мождно с сайта мелкомягких.
> Там ни слова про параллельные транзакции.
Как ты думаешь, почему?
> Р>ЗЫ. Бесплатные версии есть также у Оракла и ДБ2. Все не embedded.
> Не в одном из перечисленных нет того, что нужно:
> — несколько транзакций на сессию. тем более с разными уровнями изоляции
Сам понял что написал?
> — минимальные затраты на развёртывание (положил DLL в каталог продукта и
> все. Или еще проще — прилинковал либы в экзешник).
см. выше.
> — открытые исходники с возможностью модификации.
Это ты сам выдумал?

> Итого: к чему вообще был этот пост?
Не к тебе.

Posted via RSDN NNTP Server 2.1 beta

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

КД>Не перегибай палку

Я вообще с палками не очень...

КД>Блин, я вот не могу понять — в чем именно проявлется усложнение?
Может ты просто по другому не пробовал?

КД>IB, ни кто не заставляет обязательно делать многопоточное приложение.
Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении?
Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.

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

КД>И что же там делается?
Где?

КД>Тестили через OLEDB. Новая параллельная транзакция порождает НОВОЕ подключение

И на 2000 и на 2005
MARS не поддерживается OLEDB, только .Net провайдером.

КД>В FB/IB можно и зачастую так и делают — в каждый момент времени только одна транзакция.
Причем тут в каждый момент? Кошерный способ работы — на каждое подключение одна активная транзакция, а уж в какой момент эти подключения идут — дело десятое.

КД>Но практикующие ведущие собаководы иногда предлагают создавать по требованию именно транзакции. Понимаешь?
И в чем проблема?

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

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

КД>Понятно. А есть возможность вообще запретить неявный старт?
Нет конечно. Все операции (за редким исключением) всегда выполняются в рамках транзакции. Без транзакции просто ничего делать невозможно.

Привет, IB!
Вы пишешь 20 сентября 2007:

[Sorry, skipped]
I> Расскажи ка мне, как ты собираешься работать с параллельными транзакциями
I> из одного подключения в однопоточном приложении?
I> Приостанавливать действие одной транзакции и запускать из того же потока другую?
I> Вот уж действительно редкое извращение.

И снова ты судишь со своей колоколни...
Кто мешает держать активной одну долгоиграющую транзакцию
READ_ONLY
READ_COMMITED
RECORD_VERSION
А для модификации данных стартовать-коммитить-ролбэчить
другую транзакцию — "параллельную".
Где тут так нелюбимая тобой многопоточность?

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

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

AC>>Кто мешает держать активной одну долгоиграющую транзакцию
IB>Зачем? Можешь мне придумать сценарий когда это надо?
IB>Неговоря уже о том что сам факт "долгоиграющей" транзакции говорит о том, что что-то там не так напроектировали.

Мда... Иван, иногда они возникают "сами по себе".

У нас такое сплошь и рядом, когда начинают днем заливать в рабочую базу, на которой висит под сотню пользователей, пакеты репликации. Бывают пакеты маленькие (относительно короткие транзакции). Бывают достаточно большие — тут как повезет.

Или формировать пакеты репликации.

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

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

>> Ну, с исторической точки зрения FireBird тут совсем ни при чем.
>> "Перемутил" Джим в незапамятные времена.
>> За что многие люди (и я) ему благодарны.
Р>Гм... Он не задумывался анд тем, что вы так извратите его идеи.

Что бы небыло споров, можешь у него сам спросить. Адрес известен.

>>> > Embeded?
>> Р>Нет.
>> Это было одно из требований.
Р>Это было с грифом "желательно".
То есть тоже требование, хоть и не обязательное...
В софистике поупражняйся в другом месте.

>>> > А поподробней, где почитать про всё это применительно к MS SQL?
>> Р>BooksOnLine. Скачать мождно с сайта мелкомягких.
>> Там ни слова про параллельные транзакции.
Р>Как ты думаешь, почему?
А фигли мне думать? Вы мне и расскажете, если конечно сами в курсе

>> Р>ЗЫ. Бесплатные версии есть также у Оракла и ДБ2. Все не embedded.
>> Не в одном из перечисленных нет того, что нужно:
>> — несколько транзакций на сессию. тем более с разными уровнями изоляции
Р>Сам понял что написал?
Я то вполне. А вот ты походу срываешься. Аргументы кончились? Или их и небыло?

>> — минимальные затраты на развёртывание (положил DLL в каталог продукта и
>> все. Или еще проще — прилинковал либы в экзешник).
Р>см. выше.
Выше у меня голубое небо. Но туда я пока не хочу.

>> — открытые исходники с возможностью модификации.
Р>Это ты сам выдумал?
Ага. Потому как оно мне надо.

>> Итого: к чему вообще был этот пост?
Р>Не к тебе.
Походу _не к тебе_ гораздо больше.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

КД>>IB, ни кто не заставляет обязательно делать многопоточное приложение.
IB>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении?
IB>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.

Походу имеется недопонимание.
Параллельные != одновременно (синхронно) выполняющиеся в клиенте.

Пример однопоточной параллельности:
старт первой транзакции (1).
старт вотрой транзакции (2).
в (1) фетч данных
в (2) адейт записи, входящей в отфетченный набор из (1)
commit (2)
рефетч уже запрепаренного запроса в (1)
commit/rolback (1) (не имеет значения, модификации не проводились).
Итого: в рамках одного подключения последовательно-параллельным способом получены данные, живущие в сервере.
ну конечно параметры изоляции учитывать нужно.

Ну и жизненный пример от Ded'а:
Редактирования и коммита в вызываемых модулях и использование
проделанных модификаций в вызывающих без перечитывания ВСЕГО. Например,
ввод клиента в процессе ввода счёта. Можно и в одной [транзакции], но замумукашься в
боле-мене сложном структурно функционале отслеживать в каком состоянии
была единственная транзакция на входе в модуль и надо ли её коммитить на
выходе и как откатить изменения функции не откатывая изменений в
вызвавшей её функции и во всех вызванных из неё ранее.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

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

AC>Аналогичный вопрос: ты можешь показать, на пальцах, для тупых, чем это плохо?
Тем что расходуются ресурсы сервера.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

КД>Мда... Иван, иногда они возникают "сами по себе".
Так будет сценарий или нет?

КД>Если начнут посередине дня резервировать базу целиком — ну тоже часа полтора транзакция будет висеть. База-то немаленькая, хотя и работает на мега-коне.
Ну допустим (кхм..). И вот тот самый поток который заливает пакет репликации в одной транзакции, приостанавливает это дело и запускает другие транзакции, пока репликация курит?
Нда, и эти люди запрещают мне ковыряться в носу..

... << RSDN@Home 1.2.0 alpha rev. 673>>

Привет, IB!
Вы пишешь 20 сентября 2007:

AC>> Аналогичный вопрос: ты можешь показать, на пальцах, для тупых, чем это плохо?
I> Тем что расходуются ресурсы сервера.

Какого именно сервера, Иван?
Какие именно ресурсы?
И как соотносится сей "перерасход" с аналогичным,
но в случае "параллельного коннекта", а не транзакции?

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

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

SM>Походу имеется недопонимание.
Определенно.

SM>Параллельные != одновременно (синхронно) выполняющиеся в клиенте.
Уух.. параллельно — это асинхронно, синхронно — это последовательно.

SM>в (1) фетч данных
SM>в (2) адейт записи, входящей в отфетченный набор из (1)
Транзакция обладает ACID-ностью. Буковка I — изолированность. На практике это означает, что транзакция (2) не может увидеть результат работы транзакции (1), до тех пор, пока (1) не зафиксировалась. Если позволить делать такие фокусы, то это приведет к эффекту Cascading Aborts — если ранзакция (2) зафиксируется, а транзакция (1) по каким-то причинам не сможет, то и (2) надо тоже откатывать. Более того, надо откатывать все транзакции, которые к этому времени успели попользоваться изменениями всесенными (2) — и далее по цепочке. Если этого не делать, то окажется что транзакция (2) зафиксировала данные, которые никогда не существовали.

SM> Например, ввод клиента в процессе ввода счёта.
Ввод клиента в процессе ввода счета — это несколько транзакций.

SM>Можно и в одной [транзакции], но замумукашься в боле-мене сложном структурно функционале отслеживать в каком состоянии
SM>была единственная транзакция на входе в модуль и надо ли её коммитить на выходе
Вот это, кстати, не вопрос. как только пошло что-то не то, транзакцию надо откатывать.

SM> и как откатить изменения функции не откатывая изменений в вызвавшей её функции и во всех вызванных из неё ранее.
Так у нас транзакция или нет? Если транзакция, то надо откатывать все, безвопросов, елси не все, значит это несколько последовательных транзакций.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

КД>>Понятно. А есть возможность вообще запретить неявный старт?
IB>Нет конечно. Все операции (за редким исключением) всегда выполняются в рамках транзакции. Без транзакции просто ничего делать невозможно.

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

И долго-долго спорил на форуме FB по связанной теме "а нужен ли на уровне клиента парсер SQL-запросов"

---
Я про то, чтобы вообще запретить неявные старты. В IBProvider можно запрещать старты как для юзерских нужд, так и для внутренних (например, для чтения метаданных).

Для MSSQL-ных компонент такое возможно?

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

SM>>в (1) фетч данных
SM>>в (2) адейт записи, входящей в отфетченный набор из (1)
IB>Транзакция обладает ACID-ностью. Буковка I — изолированность. На практике это означает, что транзакция (2) не может увидеть результат работы транзакции (1), до тех пор, пока (1) не зафиксировалась. Если позволить делать такие фокусы, то это приведет к эффекту Cascading Aborts — если ранзакция (2) зафиксируется, а транзакция (1) по каким-то причинам не сможет, то и (2) надо тоже откатывать. Более того, надо откатывать все транзакции, которые к этому времени успели попользоваться изменениями всесенными (2) — и далее по цепочке. Если этого не делать, то окажется что транзакция (2) зафиксировала данные, которые никогда не существовали.

Наоборот. (1) увидит изменения, привнесённые (2). Естественно после того, как (2) закомититься.
И это польностью и без противоречий ложиться в теорию.
Поэтому, больша просьба читать не по диагонали, иначе все превращается в флейм.
И не нужно мне объяснять про виды транзакций. В данном топике тема немного о другом.

SM>> Например, ввод клиента в процессе ввода счёта.
IB>Ввод клиента в процессе ввода счета — это несколько транзакций.
Ага. Но не несколько соединений.

SM>>Можно и в одной [транзакции], но замумукашься в боле-мене сложном структурно функционале отслеживать в каком состоянии
SM>>была единственная транзакция на входе в модуль и надо ли её коммитить на выходе
IB>Вот это, кстати, не вопрос. как только пошло что-то не то, транзакцию надо откатывать.
Про документ — согласен.
А ввод нужного клиента

SM>> и как откатить изменения функции не откатывая изменений в вызвавшей её функции и во всех вызванных из неё ранее.
IB>Так у нас транзакция или нет? Если транзакция, то надо откатывать все, безвопросов, елси не все, значит это несколько последовательных транзакций.
И ввод нужного клиента то же?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

Alex.Che пишет:

Господа, ваш спор беспочвенен.
Оба варианта взаимодействия клиента и сервера имеют
право на жизнь.

По сути при общении клиента и сервера используются
несколько контекстов
-- контекст для передачи данных между ними
-- контекст для управления транзакциями.
-- контекст для управления потоком выполнения комманд.

У каких-то СУБД они совпадают все три, у каких-то
как-то разделены, это не имеет большого значения
и не влияет напрямую на производительность, при условии,
что все компоненты СУБД реализованы правильно.

Как это влияет на производительность — зависит исключительно
от странностей конкретной СУБД, а не от выбранного подхода.

Например, в IBase при коннекте может порождаться новый процесс ОС,
в Sybase ASE не порождается даже тред. Но это никак не связано
с реализацией или не реализацией парралельных транзакций.

Posted via RSDN NNTP Server 2.1 beta

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

SM> (1) увидит изменения, привнесённые (2). Естественно после того, как (2) закомититься.
Так в чем тогда проблема стартовать (1) после того как (2) зафиксировалась?

SM>Ага. Но не несколько соединений.

Да байта ради. Но это несколько последовательных транзакций в одном соединении.

SM>А ввод нужного клиента

Что ввод клиента?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

SM>> (1) увидит изменения, привнесённые (2). Естественно после того, как (2) закомититься.
IB>Так в чем тогда проблема стартовать (1) после того как (2) зафиксировалась?
Ещё раз. Читать нужно не по диагонали.
(2) меняет данные на основании фетча из (1). А (1) видит эти измененя после коммита (2).

SM>>Ага. Но не несколько соединений.

IB>Да байта ради. Но это несколько последовательных транзакций в одном соединении.
Которые и называются "параллельными". Так как в одном соединении в одно и то же время могут быть несколько активнывх транзакций.
Про что собственно я и толкую.

SM>>А ввод нужного клиента

IB>Что ввод клиента?
Опять по диагонали читаем?
см пример от Ded'а.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

КД>> И есть скрытое глобальное место, где таки хранятся готовые подключения. Называется пулом. Пулом подключений. Не можно, конечно, без пула — да ради бога — указываем "OLE DB Services=0" и вперед к тормозам

IB>Ну, то есть в IB своего пула нет и поэтому они считают, что пихать в один коннект несколько транзакций это круто, я правильно понял?

Давай мы не будем отклоняться от основной темы.

КД>>Мдаа... Берем тривиальную задачу — запись логического лога в базу данных.
IB>Для записи лога есть 33 способа, не говоря уже о том, что писать лог практически в то же хранилище где лежат и основные данные не очень правильно.

Как там папа сказал в индонезии — единство в разнообразии.

КД>>Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет.
IB>То есть, две транзакции из одного потока могут видеть незакоммиченые данные друг-друга? Прости, но это уже не транзакции.

С какого перепугу? Не выдавай желаемое за действительное.

КД>>Поэтому у этого протоколирующего объекта должна быть собственная (короткая) транзакция.
IB>Угу, но она не должна видеть незакоммиченых данных основной.

Она и не видет. А зачем ей их видеть?

КД>>... Заявления что паралельные транзакции имееют смысл только в раздельных потоках очень похоже на требование работы с разными файлами исключительно в разных потоках.
IB>Ребята, у вас нет ощущения что вы делаете что-то не то?

Лично мне не кажется.

КД>>... Иван, завязывай с линейным мышлением. На улице уже даже не объектно-ориентированное время. В один корпус кучу ядер интегрируют, а ты не можешь понять зачем несколько транзакций засовывают в одной трубе подключения.
IB>Ты сам-то понимаешь, зачем это делаешь?

Конечно понимаю

Я понимал это еще в прошлом веке. Тогда же когда просмотрел спецификацию OLEDB и сравнил с возможностями MSSQL / Interbase, понял что в Microsoft работают люди у которых мозги не зациклены на собственном Я.

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

А что там внутри делается, мы значит описать не в состоянии?

КД>>Я просил тебя написать простенький пример, который подтверждает возможность старта параллельной транзакции без открытия нового подключения. Слив как, защитывать?
IB>MSDN открой.

КД>> Понимаешь, Firebird это сервер для людей у которых как-то более продвинутая способность к восприятию мира
IB>Вот тут у меня серьезные сомнения. Я бы скорее использовал термин "измененное сознание".

КД>> и они не возможности сервера натягивают на предметную область, а наоборот
IB>Ну, нормальные люди предпочитают просто использовать адекватные инструменты, вместо того чтобы что-то на что-то натягивать.

Я так понял, вместо того чтобы пытаться разобраться и объяснить конкретные вещи, ты будешь очень рьяно оберегать свой статус. Ну что же. Реальные люди, а мне к счастью доводилось общаться с такими, ведут себя по-другому.

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

SM>(2) меняет данные на основании фетча из (1).
То есть (2) видит незафиксированные данные (1), и кто после этого читает по диагонали?

SM>Которые и называются "параллельными".
Нет, они последовательные. Транзакция не может начаться, пока не зафиксируется предыдущая, если так понятнее.

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

SM>Про что собственно я и толкую.
Угу и я.

SM>см пример от Ded'а.
Я уже ответил на этот пример.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

КД>Давай мы не будем отклоняться от основной темы.
Это собственно то, с чего начался разговор.

КД>Как там папа сказал в индонезии — единство в разнообразии.
Вот только причем тут разнообразие...

КД>С какого перепугу? Не выдавай желаемое за действительное.
Я не выдаю. Ты сам-то внимательно прочитал, что пишешь?

КД>Она и не видет. А зачем ей их видеть?
Чтобы записать в лог.

КД>Лично мне не кажется.
Хм, помоему самое время задуматься над этим..

КД>Конечно понимаю

Я понимал это еще в прошлом веке.
Похоже пришло время переосмыслить..

КД>А что там внутри делается, мы значит описать не в состоянии?

Я уже устал описывать как, зачем и почему.

КД>Я так понял, вместо того чтобы пытаться разобраться и объяснить конкретные вещи,
Я тебе объяснил очень конкретные вещи. Я не виноват, что ты их игнорируешь.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

Пример сценария, на пальцах и формочных примитивах, может так всем будет понятнее:

Пользователь начинает создание нового документа(пусть какая-то заявка). Одновременно с открытием формы стартуется транзакция Т1, которая будет АКТИВНА, читай незакомичена, все время, пока пользователь делает/редактирует документ. Версионная архитектура может себе позволить такие транзакции не сильно напрягаясь.

В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2. Заметим, эти изменения справочника должны остаться в БД, даже если пользователь откатит Т1. И только по завершению редактирования документа комитится Т1.
Т1 и Т2 как раз и есть, то, что называют параллельными транзакциями в этой ветке.

Так вот, подобный сценарий, в ФБ реализуется в рамках одного соединения, в то время как...
Говорить, что такой стиль разработки неверен — не стоит, в некоторых случая это более чем адекватно.

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

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

SM>>(2) меняет данные на основании фетча из (1).
IB>То есть (2) видит незафиксированные данные (1), и кто после этого читает по диагонали?
С какого перепугу?
В транзакции (1) данные были зафетчены (забраны с сервера). Причем данные на состояние старта (1). Все другие транзакции, модифицирующие кортеж из (1) не смогут отказать никакого вляния на кортеж из (1) до своего коммита.
В транзакции (2) были модифицированы некоторые строки кортежа (1). После коммита транзакции (2) изменения, внесённые ею стали видны в транзакции (1).
Так что пока я никак не могу увидеть, как транзакция (2) видит незафиксированные данные из (1).

Да. Забыл. IB/FB — версионник

SM>>Которые и называются "параллельными".
IB>Нет, они последовательные. Транзакция не может начаться, пока не зафиксируется предыдущая, если так понятнее.
Эт откуда такая категоричность?
Ничего, что у меня прямо сейчас три модифицирующие транзакции на одни и те же данные из одного соединения стартануты?

SM>> Так как в одном соединении в одно и то же время могут быть несколько активнывх транзакций.
IB>Нет в этом смысла. Нельзя так делать и не несет это никакой практической ценности, я уже усталписать почему.
Угу. Вопрос стереотипов.
Но изначально человеку было всё это нужно:
А может вообще уйти с Firebird?

SM>>см пример от Ded'а.
IB>Я уже ответил на этот пример.
Как то я аргументированных объяснений не увидел

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

SM>>>см пример от Ded'а.
IB>>Я уже ответил на этот пример.
SM>Как то я аргументированных объяснений не увидел

Готов поспорить, на это будет ответ:
"Объяснения были вполне аргументированные"

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

P>Пользователь начинает создание нового документа(пусть какая-то заявка). Одновременно с открытием формы стартуется транзакция Т1, которая будет АКТИВНА, читай незакомичена, все время, пока пользователь делает/редактирует документ. Версионная архитектура может себе позволить такие транзакции не сильно напрягаясь.
Позволить можно все. Но напрягаться придется сильно.

P>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2.
T1 видит эти изменения?

P>Так вот, подобный сценарий, в ФБ реализуется в рамках одного соединения, в то время как...
То есть там дорого создавать коннекты и они нашли такой выход изположения — так?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

P>>Пользователь начинает создание нового документа(пусть какая-то заявка). Одновременно с открытием формы стартуется транзакция Т1, которая будет АКТИВНА, читай незакомичена, все время, пока пользователь делает/редактирует документ. Версионная архитектура может себе позволить такие транзакции не сильно напрягаясь.
IB>Позволить можно все. Но напрягаться придется сильно.
Нет напряга. Вообще никакого.

P>>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2.
IB>T1 видит эти изменения?
После коммита T2?
Конечно.

P>>Так вот, подобный сценарий, в ФБ реализуется в рамках одного соединения, в то время как...
IB>То есть там дорого создавать коннекты и они нашли такой выход изположения — так?
На счет "дорого" единого ответа нет и быть не может.
Потому как для IB/FB есть несколько архитектур. На одной относительно дорого, на другой вообще ничего не стоит.
Вопрос в другом. В удобстве разработки и построения архитектуры приложения, используя данные возможности.
Так вот на текущий момент времени IB/FB располагает достаточной гибкостью в этом плане.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SM> С какого перепугу?
"(2) меняет данные на основании фетча из (1)" — означает, что (2) имеет доступ к незафиксированным данным из (1). Или есть какая-то другая, недоступная мне интерпретация данной фразы?

SM> В транзакции (1) данные были зафетчены (забраны с сервера). Причем данные на состояние старта (1).
Что мешает в момент старта (1) забрать данные с сервера и зафиксировать эту транзакцию, а потом начинать работать с (2)? Зачем держать транзакцию открытой, если по твоим же словам "commit/rolback (1) (не имеет значения, модификации не проводились)"?
Что-то ты со своим примером сам запутался...

SM> Так что пока я никак не могу увидеть, как транзакция (2) видит незафиксированные данные из (1).
(2) видит данные из (1) в процессе работы (1) (до того как (1) зафиксировалась), это означает, что (2) видит незафиксированные данные (1) так как дать гарантию, что данные в (1) не менялись в процессе ее работы, никто не может.

SM> Да. Забыл. IB/FB — версионник

Такое не забывается (

SM> Эт откуда такая категоричность?
Это не категоричность, это я поясняю что я сказал, если до этого не понятно было.

SM> Угу. Вопрос стереотипов.
Не стереотипов, а практики.

SM> Но изначально человеку было всё это нужно:
SM> А может вообще уйти с Firebird?
Изначально человеку нужно ехать, а не шашечки. Как это "ехать" делается, с помощю дополнительного коннекшена или нет — дело десятое, тем более что на embedded один фиг все через shared memory гуляет на приличных серверах.

SM>Как то я аргументированных объяснений не увидел

Да я что-то даже не увидел на что тут можно аргументировано возразить...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

SM> Нет напряга. Вообще никакого.
Вот я своими глазами видел как SAP-овское приложение, по такой схеме, кладет Оракл на 25-30 пользователях совершенно без напряга. Ну, ребята нашли простой выход, они на этот продукт больше 20 лицензий не продают... Вы так же поступаете?

IB>>T1 видит эти изменения?
SM> После коммита T2?
SM> Конечно.
Ты за него не отвечай, он сам справится.

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

SM> Так вот на текущий момент времени IB/FB располагает достаточной гибкостью в этом плане.
Ну правильно, освоили пулинг, появилась гибкость и человеческий подход, без изнурительных приседаний вокруг одного соединения.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

SM>> С какого перепугу?
IB>"(2) меняет данные на основании фетча из (1)" — означает, что (2) имеет доступ к незафиксированным данным из (1). Или есть какая-то другая, недоступная мне интерпретация данной фразы?
Хм. А кто вообще запускает транзакции?
Может клиент? А?
А клиент что видит? Правильно.
Так що в лес.

SM>> В транзакции (1) данные были зафетчены (забраны с сервера). Причем данные на состояние старта (1).
IB>Что мешает в момент старта (1) забрать данные с сервера и зафиксировать эту транзакцию, а потом начинать работать с (2)? Зачем держать транзакцию открытой, если по твоим же словам "commit/rolback (1) (не имеет значения, модификации не проводились)"?
В рамках самого сервера для данного примера ничего не мешает. Но изначально разговор шёл о параллельных транзакциях. И тебе пытались объяснить на примерах, как можно сделать.
Более сложные примеры ты не понимаешь к сожалению.

Если есть желание можешь почитать это: http://www.interbase-world.com/ru/articles/2509.php
А потом с новыми знаниями помедитировать над примерам, которых тебе тут накидали гору.

SM>> Так что пока я никак не могу увидеть, как транзакция (2) видит незафиксированные данные из (1).
IB>(2) видит данные из (1) в процессе работы (1) (до того как (1) зафиксировалась), это означает, что (2) видит незафиксированные данные (1)
Вообще все эти данные видит клиент, который и управляет транзакциями.
Так що это твое утверждение в лес.

IB>так как дать гарантию, что данные в (1) не менялись в процессе ее работы, никто не может.
Ну вот, приехали.
rtfm. Ссылку я те дал выше.
Да, загляни еще сюда: http://www.interbase-world.com/ru/articles/index.php?SHOWALL_2=1&BID=24&ID=72#nav_start_2
И обрати внимание, кто тебе много и терпиливо объяснял в соседней подветке.

SM>> Эт откуда такая категоричность?
IB>Это не категоричность, это я поясняю что я сказал, если до этого не понятно было.
Ты поясняешь только то, что вообще не врубаешься в тему.
Твое пояснение относится больше ко вложенным тразакциям (savepoints), а не к параллельным.
В лес.

SM>> Угу. Вопрос стереотипов.
IB>Не стереотипов, а практики.
С софистикой к богословам.

SM>> Но изначально человеку было всё это нужно:
SM>> А может вообще уйти с Firebird?
IB>Изначально человеку нужно ехать, а не шашечки. Как это "ехать" делается, с помощю дополнительного коннекшена или нет — дело десятое, тем более что на embedded один фиг все через shared memory гуляет на приличных серверах.
Человек про ехать сказал конкретно: параллельные транзакции.
Если ты не знаешь, что это такое, то это не значит, что человеку это не нужно.
Так що и это твое утверждение в лес.

SM>>Как то я аргументированных объяснений не увидел

IB>Да я что-то даже не увидел на что тут можно аргументировано возразить...
Мдя. Роман почти правильно увидел будущее...

P.S. Дальнейший разговор мне кажеться полностью бессмысленным.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

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

SM>> Нет напряга. Вообще никакого.
IB>Вот я своими глазами видел как SAP-овское приложение, по такой схеме, кладет Оракл на 25-30 пользователях совершенно без напряга. Ну, ребята нашли простой выход, они на этот продукт больше 20 лицензий не продают... Вы так же поступаете?
Ты не поверишь, но я своими глазами видел под сотню активных клиентов в CRM на такой схеме под Yaffil.
И дятел как-то не сильно напрягался.
И под ораклом наш SAP не ложиться от 20 клиентов

А на счет положить любой сервак кривым проектированием — это не ко мне. Ну или если ко мне, то ты опоздал лет так на 13...

IB>>>T1 видит эти изменения?
SM>> После коммита T2?
SM>> Конечно.
IB>Ты за него не отвечай, он сам справится.
Ты думаешь, ответы будут различаться?
Или меня боишься?

SM>> Вопрос в другом. В удобстве разработки и построения архитектуры приложения, используя данные возможности.
IB>О! Так вот я тебе как краевед скажу. Разрабатывать архитектуру приложения, когда ты четко знаешь, что у тебя на одну активную транзакцию одно подключение и это дешево — очень удобно. Другие схемы по удобству просто отдыхают. Я конечно могу придумать сценарий, когда выгоднее использоват несколько транзакций из одного подключения, но это суровая экзотика с изнурительной многопоточностью. И это опять-таки выгоднее, но ни разу не удобнее.

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

SM>> Так вот на текущий момент времени IB/FB располагает достаточной гибкостью в этом плане.
IB>Ну правильно, освоили пулинг, появилась гибкость и человеческий подход, без изнурительных приседаний вокруг одного соединения.
Пуллинг чего? Коннектов?
Ну так его ещё и проектировать нужно под другие серваки.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SM>> Нет напряга. Вообще никакого.
IB>Вот я своими глазами видел как SAP-овское приложение, по такой схеме, кладет Оракл на 25-30 пользователях совершенно без напряга. Ну, ребята нашли простой выход, они на этот продукт больше 20 лицензий не продают... Вы так же поступаете?

Самое смешное в этом то, что в Оракле тоже нет параллельных транзакций

И коннект у него не дешевый...
Если я правильно понял то, о чем ты хотел сказать своим примером.

IB>>>T1 видит эти изменения?
SM>> После коммита T2?
SM>> Конечно.
IB>Ты за него не отвечай, он сам справится.

Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился?
Только вот какое отношение это все имеет к поднятому вопросу?

SM>> Вопрос в другом. В удобстве разработки и построения архитектуры приложения, используя данные возможности.
IB>О! Так вот я тебе как краевед скажу. Разрабатывать архитектуру приложения, когда ты четко знаешь, что у тебя на одну активную транзакцию одно подключение и это дешево — очень удобно.

Ну, тоже самое можно сказать и наоборот — вопрос привычки и наработанных решений, не так ли?

SM>> Так вот на текущий момент времени IB/FB располагает достаточной гибкостью в этом плане.
IB>Ну правильно, освоили пулинг, появилась гибкость и человеческий подход, без изнурительных приседаний вокруг одного соединения.

Иван, уже передергиваете. Вокруг соединения никто не приседает, описываемый подход не менее трудоемок, чем с несколькими соединениями. Об этом вам говорят люди пробовавшие ОБА подхода. А вы, зашорившись, не очень красиво настаиваете на преимуществе только одного, вам известного. Или я не прав, и вы использовали в своей практике оба подхода, и наработали достаточно опыта для того, что бы их сравнивать?

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

MZ>Господа, ваш спор беспочвенен.

MZ>У каких-то СУБД они совпадают все три, у каких-то
MZ>как-то разделены, это не имеет большого значения
MZ>и не влияет напрямую на производительность, при условии,
MZ>что все компоненты СУБД реализованы правильно.

так мы ж с этим не спорим. это наоборот, нам пытаются
доказать, что несколько транзакций на соединение не имеют смысла.
В MS SQL они может и не имеют смысла. Опять же, с этим не спорим.

MZ>Например, в IBase при коннекте может порождаться новый процесс ОС,

это только в классике. в супере — новый тред, или используется
имеющийся тред.

MZ>в Sybase ASE не порождается даже тред. Но это никак не связано
MZ>с реализацией или не реализацией парралельных транзакций.

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

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

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

КД>>Мда... Иван, иногда они возникают "сами по себе".
IB>Так будет сценарий или нет?

в IB/FB бэкап производится в транзакции snapshot.
как только стартанули бэкап — он стартовал транзакцию
и пошел читать данные и сохранять их. Никому это особо не мешает.

КД>>Если начнут посередине дня резервировать базу целиком — ну тоже часа полтора транзакция будет висеть. База-то немаленькая, хотя и работает на мега-коне.
IB>Ну допустим (кхм..). И вот тот самый поток который заливает пакет репликации в одной транзакции, приостанавливает это дело и запускает другие транзакции, пока репликация курит?

не надо путать параллельное выполнение действий на сервере с действиями на клиенте.
сервер не перестанет выполнять операции параллельно, если кто-то стартует транзакцию.
Придумать такое — это ж надо...

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

КД>>Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет.
IB>То есть, две транзакции из одного потока могут видеть незакоммиченые данные друг-друга? Прости, но это уже не транзакции.

здесь речь вот про что. пусть даже ты открыл 2 транзакции каждую в своем коннекте.
Но в ОДНОМ приложении. В этом смысле "транзакция1" может "увидеть" данные
"транзакции2". То есть, я в приложении могу прочитать запись в контексте одной транзакции,
и на основании этих данных что-то сделать в другой транзакции.
непонятно, почему тебе это непонятно.

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

P>>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2.
IB>T1 видит эти изменения?

мне непонятны эти инсинуации в сторону уровней изолированности в IB.
Участники форума могут ошибаться в том что они пишут, или излагать
свои мысли нечетко, но это не изменит того, что:

в IB/FB транзакции реализованы в соответствии со стандартом и требованиями ACID.
транзакции в IB/FB поддерживают два уровня изолированности:
Read Committed
SNAPSHOT.
при этом SNAPSHOT является более сильным уровнем, чем стандартный
Repeatable Read (см. статью "Критика уровней изолированности в стандарте ANSI SQL).

Надеюсь, после такой информации вопросы о том, какая транзакция чего видит,
отпадут.

p.s. кроме того, существуют вариации параметров транзакций, которые никак ACID
не нарушают.
p.p.s. snapshot и RC в IB/FB тот же самый, что и например в Оракле. Или в Африке.

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

А>Вы меня извините, но это нонсенс. где тут изнурительное программирование?
А> ...
А> TR1.StartTransaction;
А> ...
А> TR2.StartTransaction;
А> ...
А> TR1.Commit;
А> TR2.Rollback;
Ничего сложного, только к примеру в ADO.NET 2.0 на один коннект такое невозможно.
в других средах разработки возможно, но кто Вам сказал что не порождается новая сессия на сервере?

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

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

КД>>>Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет.
IB>>То есть, две транзакции из одного потока могут видеть незакоммиченые данные друг-друга? Прости, но это уже не транзакции.

КДВ>здесь речь вот про что. пусть даже ты открыл 2 транзакции каждую в своем коннекте.
КДВ>Но в ОДНОМ приложении. В этом смысле "транзакция1" может "увидеть" данные
КДВ>"транзакции2". То есть, я в приложении могу прочитать запись в контексте одной транзакции,
КДВ>и на основании этих данных что-то сделать в другой транзакции.
КДВ>непонятно, почему тебе это непонятно.
Да хоть из разных приложений можно увидеть то что сделали в другом при условии что еще и коммит не сделали (Главное чтоб в транзакции произвели действия)- уровни изоляции транзакций никто не запрещал менять

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

КДВ>в IB/FB бэкап производится в транзакции snapshot.
Это проблемы IB

КДВ>как только стартанули бэкап — он стартовал транзакцию и пошел читать данные и сохранять их. Никому это особо не мешает.
ы вообще за дискуссией следишь? Причем тут бакап и инициатива сервера?

КДВ>не надо путать параллельное выполнение действий на сервере с действиями на клиенте.
Угу, не надо. Так кто тут про действия на сервере заговорил?

КДВ>Придумать такое — это ж надо...
Вот и я о том же.

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

P>Если я правильно понял то, о чем ты хотел сказать своим примером.
Нда.. не правильно.
Своим примером я хотел сказать, что даже для версионника длинные транзации- не сахар.

P>Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился?
Нет.

P>Только вот какое отношение это все имеет к поднятому вопросу?
Самое прямое. Я тут уже который раз вдалбливаю тривиальную истину, о том что свойство изолированности придумали не просто так и не следует обходить его через клиента.

P>Ну, тоже самое можно сказать и наоборот — вопрос привычки и наработанных решений, не так ли?
Нет, не так.

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

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

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

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

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

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

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

IB>Да я что-то даже не увидел на что тут можно аргументировано возразить...
Да хотя бы на это:

    IBPP::Database database = IBPP::DatabaseFactory("", "test_alias", "sysdba", "masterkey");
    CHECK_IBPP(database->Connect());

    IBPP::Transaction tr1 = IBPP::TransactionFactory(database, IBPP::amWrite, IBPP::ilReadCommitted, IBPP::lrNoWait);
    IBPP::Transaction tr2 = IBPP::TransactionFactory(database, IBPP::amWrite, IBPP::ilReadCommitted, IBPP::lrNoWait);
    ////////////////////////////////////
    // Подход первый: две транзакции - первая читает, вторая пишет что прочиталось, 
    // первая опять читает.
    ////////////////////////////////////
    TRACE_PART(_T("1"));

    tr1->Start();
    tr2->Start();
    ////////////////////////////////////

    IBPP::Statement stmr_tr1 = IBPP::StatementFactory(database, tr1, _T("select * from test1 order by ID"));
    CHECK_IBPP(stmr_tr1->Execute());

    IBPP::Row rw;
    int iVal, iSum = 0; 
    TRACE_STM_START(stmr_tr1);
    while (stmr_tr1->Fetch(rw))
    {
        TRACE_ROW(rw);
        rw->Get(_T("cnt"), iVal);
        iSum += iVal;
    }
    stmr_tr1->Close();

    IBPP::Statement stmu_tr2 = IBPP::StatementFactory(database, tr2, _T("update test1 set cnt = %d where name = 'TOTAL' "), iSum);
    CHECK_IBPP(stmu_tr2->Execute());

    CHECK_IBPP(stmr_tr1->Execute());
    TRACE_STM_START(stmr_tr1);
    while (stmr_tr1->Fetch(rw))
    {
        TRACE_ROW(rw);
    }
    stmr_tr1->Close();

    ////////////////////////////////////
    tr2->Commit();
    ////////////////////////////////////

    CHECK_IBPP(stmr_tr1->Execute());
    TRACE_STM_START(stmr_tr1);
    while (stmr_tr1->Fetch(rw))
    {
        TRACE_ROW(rw);
    }
    stmr_tr1->Close();
    tr1->Commit();

    ////////////////////////////////////
    // подход два: обе пишут, одна откатилась, вторая - нет.
    ////////////////////////////////////

    TRACE_PART(_T("2"));
    tr1 = IBPP::TransactionFactory(database, IBPP::amWrite, IBPP::ilReadCommitted, IBPP::lrNoWait);
    tr2 = IBPP::TransactionFactory(database, IBPP::amWrite, IBPP::ilReadCommitted, IBPP::lrNoWait);

    stmr_tr1 = IBPP::StatementFactory(database, tr1, _T("update test1 set name = 'test' where ID = 1 "));
    CHECK_IBPP(stmr_tr1->Execute());
    stmr_tr1->Close();

    stmr_tr1 = IBPP::StatementFactory(database, tr1, _T("select * from test1 order by ID"));
    CHECK_IBPP(stmr_tr1->Execute());
    TRACE_STM_START(stmr_tr1);
    while (stmr_tr1->Fetch(rw))
    {
        TRACE_ROW(rw);
    }
    stmr_tr1->Close();
    
    stmu_tr2 = IBPP::StatementFactory(database, tr2, _T("update test2 set tf = 'f_' || cast(ID as VARCHAR(1)) "));
    CHECK_IBPP(stmu_tr2->Execute());
    stmu_tr2->Close();

    stmu_tr2 = IBPP::StatementFactory(database, tr2, _T("select * from test2 order by ID"));
    CHECK_IBPP(stmu_tr2->Execute());
    TRACE_STM_START(stmu_tr2);
    while (stmu_tr2->Fetch(rw))
    {
        TRACE_ROW(rw);
    }
    stmu_tr2->Close();

    tr1->Rollback();
    tr2->Commit();

    // И чё получилось?

    IBPP::Transaction tr3 = IBPP::TransactionFactory(database, IBPP::amRead, IBPP::ilReadCommitted, IBPP::lrNoWait);
    stmr_tr1 = IBPP::StatementFactory(database, tr3, _T("select * from test1 order by ID"));
    CHECK_IBPP(stmr_tr1->Execute());
    TRACE_STM_START(stmr_tr1);
    while (stmr_tr1->Fetch(rw))
    {
        TRACE_ROW(rw);
    }
    stmr_tr1->Close();

    stmu_tr2 = IBPP::StatementFactory(database, tr3, _T("select * from test2 order by ID"));
    CHECK_IBPP(stmu_tr2->Execute());
    TRACE_STM_START(stmu_tr2);
    while (stmu_tr2->Fetch(rw))
    {
        TRACE_ROW(rw);
    }
    stmu_tr2->Close();

    database->Disconnect();

Output:
//////////////////////////////////////////////////////////
// 1
//////////////////////////////////////////////////////////

TRACE for statement [select * from test1 order by ID]
Fields:
ID [BIGINT] Name [VARCHAR(60)] Cnt [INTEGER]
------------------------------------------------------------
1 lksdjalksjahdlfjasf 33
2 slkdfhlgskdjgh 10
3 lskdfghldgf 44
4 TOTAL <null>

TRACE for statement [select * from test1 order by ID]
Fields:
ID [BIGINT] Name [VARCHAR(60)] Cnt [INTEGER]
------------------------------------------------------------
1 lksdjalksjahdlfjasf 33
2 slkdfhlgskdjgh 10
3 lskdfghldgf 44
4 TOTAL <null>

TRACE for statement [select * from test1 order by ID]
Fields:
ID [BIGINT] Name [VARCHAR(60)] Cnt [INTEGER]
------------------------------------------------------------
1 lksdjalksjahdlfjasf 33
2 slkdfhlgskdjgh 10
3 lskdfghldgf 44
4 TOTAL 87

//////////////////////////////////////////////////////////
// 2
//////////////////////////////////////////////////////////

TRACE for statement [select * from test1 order by ID]
Fields:
ID [BIGINT] Name [VARCHAR(60)] Cnt [INTEGER]
------------------------------------------------------------
1 test 33
2 slkdfhlgskdjgh 10
3 lskdfghldgf 44
4 TOTAL 87

TRACE for statement [select * from test2]
Fields:
ID [BIGINT] tf [VARCHAR(10)]
---------------------------------------
1 f_1
2 f_2
3 f_3
4 f_4

TRACE for statement [select * from test1 order by ID]
Fields:
ID [BIGINT] Name [VARCHAR(60)] Cnt [INTEGER]
------------------------------------------------------------
1 lksdjalksjahdlfjasf 33
2 slkdfhlgskdjgh 10
3 lskdfghldgf 44
4 TOTAL 87

TRACE for statement [select * from test2]
Fields:
ID [BIGINT] tf [VARCHAR(10)]
---------------------------------------
1 f_1
2 f_2
3 f_3
4 f_4

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

P>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2. Заметим, эти изменения справочника должны остаться в БД, даже если пользователь откатит Т1. И только по завершению редактирования документа комитится Т1.
P>Т1 и Т2 как раз и есть, то, что называют параллельными транзакциями в этой ветке.

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

P>Так вот, подобный сценарий, в ФБ реализуется в рамках одного соединения, в то время как...
P>Говорить, что такой стиль разработки неверен — не стоит, в некоторых случая это более чем адекватно.

Стоит

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

M>Знаю, что тема не нова, но время не стоит на месте...

M>Может, насоветуете альтернативную СУБД:
M>* бесплатная;
M>* параллельные транзакции;
M>* хранимые процедуры, триггеры;
M>* защита от юзверя (что раздражает в Firebird — так это божественное всемогущие SYSDBA).

Интересно, а поменять всемогущего никак не пробовали? Или это бог неменяемый?
И чем FB не устраивает? Религия не позволяет? Причины есть которые обусловили такой вопрос?

A>Интересно, а поменять всемогущего никак не пробовали? Или это бог неменяемый?
A>И чем FB не устраивает? Религия не позволяет? Причины есть которые обусловили такой вопрос?

Что-то я Вас недопонимаю... Куда Вы денетесь от SYSDBA? Если клиент не знает его пароля, он свободно переустановкой СУБД решит эту проблему и база как на ладони.
Ну а во-вторых, т. н. "параллельные транзакции" не поддерживаются его Data Provider-ом.

PS По божественным и религиозным вопросам Вы ошиблись форумом.

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

A>>Интересно, а поменять всемогущего никак не пробовали? Или это бог неменяемый?
A>>И чем FB не устраивает? Религия не позволяет? Причины есть которые обусловили такой вопрос?

M>Что-то я Вас недопонимаю... Куда Вы денетесь от SYSDBA? Если клиент не знает его пароля, он свободно переустановкой СУБД решит эту проблему и база как на ладони.
как это переустановка СУБД решит эту проблему???
для смены пароля нужно или присоедениться к БД под SYSDBA и тогда поменять пароль или пересоздать БД и перелить в неё данные, для чего нужно присоедениться с БД снять метаданные, выгрузить данные и все это можно только под учетной записью того, у кого есть права на все эти операции, и это у многих не SYSDBA
M>Ну а во-вторых, т. н. "параллельные транзакции" не поддерживаются его Data Provider-ом.
ну так затянувшаяся на третий день дисскусия по моему явно показала, что "паралельных" транзакций нет ни у каких серверов под НЕТ
M>PS По божественным и религиозным вопросам Вы ошиблись форумом.

что-же у всех с юмором

Удачи

... << RSDN@Home 1.2.0 alpha rev. 729>>

Привет, Igor_123!
Вы пишешь 21 сентября 2007:

[Sorry, skipped]
I> ну так затянувшаяся на третий день дисскусия по моему явно показала,
I> что "паралельных" транзакций нет ни у каких серверов под НЕТ

А спецификацией NET-провайдеров они предусмотрены?
Я не в курсе просто.
В спецификации OLE DB, их есть.

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

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

AC>А спецификацией NET-провайдеров они предусмотрены?
AC>Я не в курсе просто.
AC>В спецификации OLE DB, их есть.

Их и в ADODB нету. Но те кому они нужны — и через ADODB могут без проблем создавать и использовать несколько транзакций на одном соединении.

Как в прочем и управлять отдельными уровнями вложенных транзакций. Поддержка которых в ADODB ограничена тем, что BeginTrans возвращает номер уровня.

Представляешь какая засада. Все есть, но чтобы это использовать нужно хоть иногда открывать глаза.

С ADO.NET для FB тоже самое. Тем более что есть исходники. И конкретные люди заинтересованные в развитии этого драйвера.

I_>как это переустановка СУБД решит эту проблему???
I_>для смены пароля нужно или присоедениться к БД под SYSDBA и тогда поменять пароль или пересоздать БД и перелить в неё данные, для чего нужно присоедениться с БД снять метаданные, выгрузить данные и все это можно только под учетной записью того, у кого есть права на все эти операции, и это у многих не SYSDBA

Продолжаю утверждать, что к базе на клиентской машине можно запросто получить полный доступ.

M>>PS По божественным и религиозным вопросам Вы ошиблись форумом.
I_>что-же у всех с юмором

I_>Удачи

И где я там шутку пропустил?..

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

I_>>как это переустановка СУБД решит эту проблему???
I_>>для смены пароля нужно или присоедениться к БД под SYSDBA и тогда поменять пароль или пересоздать БД и перелить в неё данные, для чего нужно присоедениться с БД снять метаданные, выгрузить данные и все это можно только под учетной записью того, у кого есть права на все эти операции, и это у многих не SYSDBA

M>Продолжаю утверждать, что к базе на клиентской машине можно запросто получить полный доступ.

Вы вероятно имели ввиду работу с embedded версией в первую очередь? Так там вобще без пароля можно подключиться, проверка не проводится. Но это частный случай, и он сделан СПЕЦИАЛЬНО. А по поводу сервиса — насколько я помню работы в этом направлении ведутся. И никто не спорит что базу имея ее на руках можно открыть с помощью embedded версии или своим сервером. Но с другой стороны это и хорошо. А если Вы работаете в большой конторе, то кто вам мешает закрыться административно от хакеров? Есть рекомендации по работе с БД, и SYSDBA там указан, т.е. что с ним делать.

P.S. Сохранность информации можно достичь и другими способами, и никто не спрашивал как. А раздражение на SYSDBA надо было просто направить в русло смены его над другого, и все... Т.е. данная претензия просто непонятна, она показывает что Вы работал с БД не пытаясь углубиться в описания что и как делать. Попытка закрыть БД от пользователя не есть удобная вещь, т.к. если это программа на продажу Вас потом юзвери сьедят, если для внутреннего пользования — то совсем непонятно почему этот вопрос возник — административные рычаги никто не отменял.

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

R> Если знаете, тогда объясните пожалуйста, какие в нем могут быть незафиксированные данные?
Очень просто. Фетчим данные на клиента, потом их меняем (те, которые отфестчили на клиента — неужели это так сложнопонять?), потом этими измененными данными пользуется другая транзакция.

R>Как так никто не может?
А вот так.

R> А кто код программы, позвольте спросить, пишет? Генератор случайных чисел?
Как правило генератор случайных чисел предсказуемее.

R> Только почему вы позволяете себе утверждать, что если определенная задача в сервере X может быть решена способами A и B, а в сервере Y только способом B, то значит сервер X некошерный и способ A права на существование не имеет?
Я утверждаю, что способ X — не кошерный, вне зависимости от сервера. Почему — я пытался объяснить неоднократно.
Возможно несколько коротко, но ребята объяснений было более чем достаточно и вообще я уже сутки как в отпуске.

R>мы вчера полдня из под стола вылезти не в силах были, а нам работать надо...
Нет, ребята, не вылезайте, лучше не надо.

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

SM> Ты думаешь, ответы будут различаться?
Понятия не имею, я же его спрашивал.

SM> Или меня боишься?

Есть чего?

SM> Ты уже показал, что за рамки своего опыта не можешь выйти даже мысленно.
Думаешь есть необходимость?

SM> Ну так его ещё и проектировать нужно под другие серваки.
Нда, я подозревал, что разработчики IB ленивее чем надо и н еучатся даже на положительном опыте..

Привет, IB!
Вы пишешь 21 сентября 2007:

R>> Если знаете, тогда объясните пожалуйста, какие в нем могут быть незафиксированные данные?
I> Очень просто. Фетчим данные на клиента, потом их меняем (те, которые отфестчили на клиента —
I> неужели это так сложнопонять?), потом этими измененными данными пользуется другая транзакция.

Иван, а вот ежели я тебе скажу: "иногда лучше жевать, чем говорить!", ты меня забанишь?
Интересно просто. А то некий kuj тут так и мелькает с этой фразой, так и мелькает...

Иван, какое отношение имеют данные отфетченные на клиента, к состоянию транзакии?
Подтвержденные, неподтверждённые...
Проясни.

I> Я утверждаю, что способ X — не кошерный, вне зависимости от сервера.
I> Почему — я пытался объяснить неоднократно. Возможно несколько коротко

Дык, где же, где же?
Наводящие вопросы ты игнорируешь напрочь.
Аргументов никаких, одни эммоции...

I> но ребята объяснений было более чем достаточно и вообще я уже сутки как в отпуске.

Слив засчитан.
Отдыхай.

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

Привет, IB!
Вы пишешь 21 сентября 2007:

[Sorry, skipped]
AC>> Иван, какое отношение имеют данные отфетченные на клиента, к состоянию транзакии?
I> Ты считаешь что если данные уехали на клиента то это уже вроде ка ки не транзакция?

Иван, транзакция живет на сервере.

Что там у клиента за щекой — серверу не интересно.

AC>> Подтвержденные, неподтверждённые... Проясни.
I> Да я уже устал пояснять, ей богу.
I> Вот если вечерком будет время может напишу развернуто,
I> если вы меня окончательно не озлобите..

Ждем-с.

[Sorry, skipped]
AC>> Слив засчитан.
I> Озлобил.

Так что, не ждать развернутых комментариев?

--
With best regards, Alex Cherednichenko.

Posted via RSDN NNTP Server 2.1 beta

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

SM>> И тебе пытались объяснить на примерах, как можно сделать.
IB>Ты так и не понял, что тебе пытались объяснить почему так делать нельзя.

Объяснения методом выборочного удаления сообщений — это что-то новенькое

А вот на мессагу с демкой почему-то ответа никакого...
Может на ее примере ещё раз попробуем?

Тута

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SM>Объяснения методом выборочного удаления сообщений — это что-то новенькое

Ни одного сообщения, где было хоть что-то по делу удалено не было.

SM>А вот на мессагу с демкой почему-то ответа никакого...
потому что демка не по делу, да и времени нет.

SM>Может на ее примере ещё раз попробуем?

Давай пример.

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

IB>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении?
IB>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.

Абисняю. Все ОЧЕНЬ ПРОСТО.
Есть один TDatabase на приложение.
В каждой форме где есть запросы есть как минимум одна транзакция. она стартуется/коммитится в соответствии в логикой работы запросов на этой форме. И меня совершенно не волнует при этом что какой-то другой модуль может что-то сделать с транзакией этой формы — потому что они просто ее не видят

На всякий случай поясню — приложение однопоточное, в автокриэйте всего пара форм, остальные создаются при открытии окна и потом уничтожаются. Окна есть как модальные так и MDIChild.\

А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.

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

SЗ>Да хотя бы на это:
И причем здесь "это"?

P. S.
Никто тебя, кстати, не банил, не надо тут истерики устраивать и на публику работать.

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

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

kuj>Бритву Оккама

Разве что в плане ее неиспользования.

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

IB>Здравствуйте, Аноним, Вы писали:

А>>Абисняю. Все ОЧЕНЬ ПРОСТО.
А>>Есть один TDatabase на приложение.
IB>...
А>>А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.

IB>То есть, проблема в том, что борланд не смог написать правильную клиентскую библиотеку?

Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? Или про BDE тоже не в курсе как и про транзакции IB/FB?

Здравствуйте, IB, Вы писали:
IB>Давай откроем учебник — транзакция это совокупность операций по переводу данных из одного согласованного состояния в другое. Где и как это происходит совершенно не важно. Для того, чтобы процесс сошелся и перевод произошел именно в согласованное состояние, должны соблюдаться требования ACID.
IB>Ты серьезно думаешь, что если требоания ACID нарушатся на клиенте, а не на сервере БД, то в конечном итоге данные окажутся в более согласованном состоянии?
Тоесть, ты хочешь сказать, что не один сервер баз данных не выполняет требования ACID?
Ведь для любого сервера можно написать клиента, который их нарушит.

... << RSDN@Home 1.2.0 alpha rev. 752>>

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

T>Тоесть, ты хочешь сказать, что не один сервер баз данных не выполняет требования ACID?
Сервер БД здесь не причем.

T>Ведь для любого сервера можно написать клиента, который их нарушит.

Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.

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

A> Кто-то пользуется Вашим именем?
Кто-то посмел?

A>В данном конкретном случае UI пересекается с конкретной задачей.
Не пересекается ни в одном месте.

A>А в какую сторону у нас двигаются сейчас разработки? Что СУБД что языков программирования.
Могу лекцию прочитать, надо?

A>Вот именно что не представляю.
Пора уже расширять кругозор.

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

A>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась?
То есть, проблема в том, что BDE изначально задумывалась кривой, потому что создавалась очень давно?
Ну и что после этого валить с больной головы на здоровую?

A> Или про BDE тоже не в курсе как и про транзакции IB/FB?
Ну, сдается мне, что в BDE я разбираюсь лучше, чем все защитники FB в транзакциях, оптом..

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

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

T>>Тоесть, ты хочешь сказать, что не один сервер баз данных не выполняет требования ACID?
T>>Ведь для любого сервера можно написать клиента, который их нарушит.

IB>Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.
Хорошо, если пльзователь увидел цифирь которую прога получиа в одной транзакции, и в соответствии с ней изменил данные в другой транзакции — это как расценивать?

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

Если рассмотреть твой ответ, то ни один снервер просто не в состоянии предоставить эти самые гарантии, что бы не написал разработчик.

Или ты про что-то другое?

... << RSDN@Home 1.2.0 alpha rev. 752>>

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

P>>Если я правильно понял то, о чем ты хотел сказать своим примером.
IB>Нда.. не правильно.
IB>Своим примером я хотел сказать, что даже для версионника длинные транзации- не сахар.

Непраивльный пример. Он этого совершенно не показывает.
(будем общаться в вашем стиле).

P>>Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился?
IB>Нет.
P>>Только вот какое отношение это все имеет к поднятому вопросу?
IB>Самое прямое. Я тут уже который раз вдалбливаю тривиальную истину, о том что свойство изолированности придумали не просто так и не следует обходить его через клиента.

Ппц, я что, в пустоту говорю? Кто ее обходит? Из чего такой вывод?
Я привел пример, демонстрирующий удобство использования двух параллельных транзакций — какие обходы изолированности, Иван, окститесь!

P>> Об этом вам говорят люди пробовавшие ОБА подхода.
IB>В том-то и проблема, что об этом говорят люди пробовавшие только один подход, более того, судя по обилию и разнообразию примеров — только один тип приложений.

Эээ, ну еси это было не ясно — Я. ИСПОЛЬЗОВАЛ. ОБА. ПОДХОДА.
В разных типах приложений. И буду использовать дальше оба. Ибо в каждом случае, могу выбирать, что мне удобнее и выгоднее. Чего и все рекомендую.

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

P>>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2. Заметим, эти изменения справочника должны остаться в БД, даже если пользователь откатит Т1. И только по завершению редактирования документа комитится Т1.
P>>Т1 и Т2 как раз и есть, то, что называют параллельными транзакциями в этой ветке.
___>Офигеть, дайте две. Здесь вполне можно открыть второе соединение и там выполнить изменения справочника — какая здесь необходимость в параллельных транзакциях?

А можно не открывать. Какая здесь необходимость в двух соединениях?
Но самое приятное, что в ФБ я могу как открывать соединения, так и нет — я волен сам решать, что в данном, частном случаем, мне выгоднее(про, например, переменные сессии уже говорилось, причем не один раз....).

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

A>> Кто-то пользуется Вашим именем?
IB>Кто-то посмел?
Если нет? то Вы сами себе противоречите. Мне пишите одно, а другим другое. Или у;е не помните что писали? Я процитировал на всякий случай.

A>>А в какую сторону у нас двигаются сейчас разработки? Что СУБД что языков программирования.
IB>Могу лекцию прочитать, надо?
Да толку то. Хотя попробовать можно. Может статью напишите? Тогда флейма не будет просто еще по одному вопросу.

A>>Вот именно что не представляю.
IB>Пора уже расширять кругозор.
Сами ратуете за то чтобы расширяли кругозор, а простую истину понять не можете.... Тогда поясняю — одну задачу можно решить множеством способов. И сами способы решения зависят в основном от мышления каждого конкретного человека. Поэтому я НЕ ПРЕДСТАВЛЯЮ сколькими способами можно решить задачу. Я просто не бог. Могу привести решение любой задачи 3-4 способами стабильно. Мне этого хватает. А Вам скольких способов хватает?

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

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

A>>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась?
IB>То есть, проблема в том, что BDE изначально задумывалась кривой, потому что создавалась очень давно?
IB>Ну и что после этого валить с больной головы на здоровую?

Ну если такой подход к BDE, то вопрос закрыт. Программите на VS наверное?

A>> Или про BDE тоже не в курсе как и про транзакции IB/FB?
IB>Ну, сдается мне, что в BDE я разбираюсь лучше, чем все защитники FB в транзакциях, оптом..

Ну и отлично

Я рад что есть такой специалист.

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

A> Я процитировал на всякий случай.
О чем речь-то?

A>Да толку то. Хотя попробовать можно. Может статью напишите? Тогда флейма не будет просто еще по одному вопросу.
Да я уже десяток статей написал..

A>Сами ратуете за то чтобы расширяли кругозор, а простую истину понять не можете.
Проблема похоже в том, что я простую мысль объяснить не могу..

A> А Вам скольких способов хватает?
Достаточно одного.

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

A>Ну если такой подход к BDE, то вопрос закрыт.
Ну слава байту, хоть с одним разобрались.

A>Ну и отлично

Я рад что есть такой специалист.
А я-то как..

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

P>> Ты говоришь про какую-то систему, на Оракле, с неизвестной архитектурой и внутренностями, СЕРИАЛИЗОВАННЫМИ, вследствии архитектуры Оракла, транзакциями
IB>Ты даже не читаешь того что тебе пишут, я уже не говорю о том, чтобы попытаться понять. Это был пример про длинные транзакции, а не сериализованные — длинные, понимаешь?

Ок, и что же делалось в тех длинных транзакциях в Оракле?
Второе — сколько коннектов открывалось с одного клиента, если это была двухзвенка?

P>> Даже теоретически нигде изолированность там не нарушается,

P>> как и где, в моем примере, нарушается изолированность транзакций.
IB>Если в твоем примере изолированность транзакций не нарушается, то нет никакой причины, по которой их нельзя было бы сериализовать. Это задачка для первокласника. Таким образом, возвращаясь к началу спора, необходимости в параллельных транзакциях из одного потока — нет.
IB>Более того, возвращаясь к твоей задачке, у тебя обращение к БД идет в UI-ном потоке?

P>>??? А никто и не говорил, что они там необходимы, или обязательны — они возможны и удобны.
IB>С тем что они возможны — никто не спорит, мой поинт в том, что их использование из одного потока — вредно.

P>>Так вот, грубо говоря, там же я использовал одно подключение, но с несколькими транзакциями
IB>Ну вот я и пытаюсь понять зачем ты это делал. Так как в нормальных сценариях это сложнее, а тот ненормаьный который вы пытаетесь мне навязвть вообще не имеет права на жизнь.

P>>Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом.
IB>Ну вот надо прислушиваться к кругозору и излагаемому опыту, а не упираться в привычный сценарий.

P>> ибо я не вижу, как иначе прекратить передергивания и неаргументированные заявления.
IB>Поздно. Я знаю другой действенный способ — перенести тему в священные войны.

Какие-то нелепые и бредовые обвинения скипаю — если тебе кажет

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

Хм. Не понял — мессага не ушла или кто-то снова балуется? Хотя может и браузер глючит, но прецеденты были. Повторюсь тогда.

A>> Я процитировал на всякий случай.
IB>О чем речь-то?
Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?

A>>Сами ратуете за то чтобы расширяли кругозор, а простую истину понять не можете.
IB>Проблема похоже в том, что я простую мысль объяснить не могу..
Ну не совсем простую, но см. ниже. Я думаю что причина там. И любые споры с Вами бесполезны именно по этой причине. Все что я видел в посте, это голословные утверждения "Должно быть так и только так". Очень жаль.

A>> А Вам скольких способов хватает?
IB>Достаточно одного.
Всем доподлинно известно что любую задачу можно решить минимум 2-3 способами. Причем методики решения могут кардинально отличаться, и все будут давать правильные результаты. Именно поэтому я не могу никогда сказать, что я нашел все доступные способы решения задачи. Ну приучили меня к этому, и это мировоззрение я считаю верным, т.к. человек не бог, и я не бог. Я не могу увидеть все решения задачи, хотя вижу их по 2-3 практически всегда, а частенько и больше. Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.

P.S. И все-таки, VS? Вы на вопрос так и не ответили. Честно скажу — еще одну священную войну я заводить не собираюсь. Клянусь. Мне глубоко по барабану кто на чем пишет. Главное чтобы правильно.

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

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

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

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

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

Здравствуйте, Andyshark, Вы писали:
A>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? Или про BDE тоже не в курсе как и про транзакции IB/FB?
Ну я вот, к примеру, присутствовал на презентации BDE, когда он был новым словом во взаимодействии с СУБД. И нахлебался этого дерьма я с избытком. И совершенно с IB согласен, если что.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, <Аноним>, Вы писали:

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

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

КДВ>>> Почему там нельзя одновременно стартовать две, три, 5000 транзакций???
IB>>Для того чтобы это делать надо на клиенте заниматься изнурительным многопоточным программированием, разруливая одно соедиение между несколькими потоками. Гораздо проще и надежнее не делать этого.

А>Вы меня извините, но это нонсенс. где тут изнурительное программирование?
А> ...
А> TR1.StartTransaction;
А> ...
А> TR2.StartTransaction;
А> ...
А> TR1.Commit;
А> TR2.Rollback;

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

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

A>>Хм. Не понял — мессага не ушла или кто-то снова балуется? Хотя может и браузер глючит, но прецеденты были. Повторюсь тогда.

A>>>> Я процитировал на всякий случай.
IB>>>О чем речь-то?
A>>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?
S>Тебе же написали — сырые данные поставляет клиент. Одной рукой он пишет в T1 некие данные, читает что-то там из T1 и второй рукой пишет в T2. С точки зрения T2 эти данные являются сырыми, потому что коммита T1 еще не произошло. Если T1 откатить, а T2 закоммитить, то в базе окажется результат никогда не существовавших вычислений.

Я наверное не догоняю, но ткните меня пальцем ГДЕ клиент поставляет мне сырые данные? То что у меня на одной форме два запроса работающих в разных транзакциях (причем один селект, а другой на апдейт к примеру), то где тут сырые данные скажите мне? Первый возвращает гарантировано закоммиченные данные, второй гарантировано пишет. Никаких блокировок тем более не происходит. Если мне они нужны будут на какой-либо записи то я ее сделаю самостоятельно (или помощью запроса соответствуюего, но это уже по мере необходимости). Видно имеет место БОЛЬШОЕ недопонимание логики работы других людей, которые работают с более расширенным функционалом. И хочется загнать их в эти рамки. Кто вам сказал что я не могу использовать оба запроса в одной транзакции? Могу. Но по некоторым причинам не хочу в данном конкретном случае. Кто сказал что я не пользуюсь одной транзакцией для задачи? Я такого не говорил, я пользуюсь. Но в каждом конкретном случае рассматриваю КАК мне лучше сделать доступ к БД. Мало ли какая задача.

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

A>>Всем доподлинно известно что любую задачу можно решить минимум 2-3 способами. Причем методики решения могут кардинально отличаться, и все будут давать правильные результаты. Именно поэтому я не могу никогда сказать, что я нашел все доступные способы решения задачи. Ну приучили меня к этому, и это мировоззрение я считаю верным, т.к. человек не бог, и я не бог. Я не могу увидеть все решения задачи, хотя вижу их по 2-3 практически всегда, а частенько и больше. Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.
S>Э-эх. Опять классика кун-фу. Очень хорошо, что ты видишь 2-3 решения там, где новичок с трудом находит одно. Но это далеко не последний дан. Предрекаю тебе чувство глубокого отчаяния, которое охватит тебя через годы при попытках объяснить новичкам, почему нельзя делать некоторые вещи, даже если кажется, что они приводят к тому же результату. И ты точно так же будешь говорить "это темная сторона силы", а они будут говорить "нет учитель, есть разные способы".

Вау. Бог и иже с ним. Я свою позицию по этому вопросы высказал. Проблема в том что Вы не хотите встать на позицию оппонента. Мне вас по человечески жаль.

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

S>Здравствуйте, Andyshark, Вы писали:
A>>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? Или про BDE тоже не в курсе как и про транзакции IB/FB?
S>Ну я вот, к примеру, присутствовал на презентации BDE, когда он был новым словом во взаимодействии с СУБД. И нахлебался этого дерьма я с избытком. И совершенно с IB согласен, если что.

Хм. А я где-то говорил что я СТОРОННИК BDE? Но я сторонник того что идея то была более-менее хорошая. Если бы она была совсем дерьмовая, то она бы уже давно умерла. Или вы считаете всех кто пользует BDE придурками и дерьмохлебами? Сразу скажу — я BDE уже сто лет не пользую, ну не сnоронник я ее в чистом виде. Но для своего времени это было очень даже и неплохо. Можете отделить идею от реализации? И учетом того КОГДА идея была сделана?

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

A>Хм. А я где-то говорил что я СТОРОННИК BDE? Но я сторонник того что идея то была более-менее хорошая.
Для примерно так двенадцатилетней давности. Сейчас — скорее глупость.

A>Если бы она была совсем дерьмовая, то она бы уже давно умерла.
Так ведь умерла.

A>Или вы считаете всех кто пользует BDE придурками и дерьмохлебами? Сразу скажу — я BDE уже сто лет не пользую, ну не сnоронник я ее в чистом виде. Но для своего времени это было очень даже и неплохо. Можете отделить идею от реализации? И учетом того КОГДА идея была сделана?
Если сейчас явно строить новые приложения на BDE — то это уже что-то странное. Естественно, поддержка старых приложений и legacy-систем — это отдельный вопрос.

Здравствуйте, Andyshark, Вы писали:
A>>>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?
S>>Тебе же написали — сырые данные поставляет клиент. Одной рукой он пишет в T1 некие данные, читает что-то там из T1 и второй рукой пишет в T2. С точки зрения T2 эти данные являются сырыми, потому что коммита T1 еще не произошло. Если T1 откатить, а T2 закоммитить, то в базе окажется результат никогда не существовавших вычислений.
A>Я наверное не догоняю, но ткните меня пальцем ГДЕ клиент поставляет мне сырые данные?
Я написал. Все результаты изменений, сделанных в одной транзакции, будут сырыми данными для другой. Именно поэтому сервер не даст второй транзакции "увидеть" эти изменения.
Но клиент может перенести их руками.

A>То что у меня на одной форме два запроса работающих в разных транзакциях (причем один селект, а другой на апдейт к примеру), то где тут сырые данные скажите мне?
A>Первый возвращает гарантировано закоммиченные данные
Кто тебе сказал? Вот тебе простой сценарий:
T1:

update table1 set data = data + 100 where ID = 1
select data from table1 where ID=1

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

update table2 set data = 150 where id=1

вот эти 150 — это сырые данные. Семантика запроса вроде бы такая ж, как если бы мы напрямую написали

update table2 set data = (select data from table1 where id=1) where id=1

Но в таком раскладе нам СУБД не даст выстрелить себе в ногу. В зависимости от архитектуры сервера и выбранного уровня изоляции такой апдейт либо заблокируется в ожидании коммита T1, либо скопирует "старое" значение из table1. В итоге, всё останется согласованным.

Но в описываемом варианте программист ловко обходит защиту и пишет 150 в T2. Если выполнить T1.Rollback, то в базе останется значение, посчитанное непонятно откуда.

A>, второй гарантировано пишет. Никаких блокировок тем более не происходит. Если мне они нужны будут на какой-либо записи то я ее сделаю самостоятельно (или помощью запроса соответствуюего, но это уже по мере необходимости). Видно имеет место БОЛЬШОЕ недопонимание логики работы других людей, которые работают с более расширенным функционалом.
Никакого непонимания нет. Увы. Я работал с СУБД с 12 лет. Термин "РЕБУС" что-нибудь говорит? И с т.н. "более расширенным" функционалом, и с менее расширенным.
A>И хочется загнать их в эти рамки. Кто вам сказал что я не могу использовать оба запроса в одной транзакции? Могу. Но по некоторым причинам не хочу в данном конкретном случае. Кто сказал что я не пользуюсь одной транзакцией для задачи? Я такого не говорил, я пользуюсь. Но в каждом конкретном случае рассматриваю КАК мне лучше сделать доступ к БД. Мало ли какая задача.
Доступ к БД — это техническая подробность. У наших пользователей есть очень много потребностей. Нам надо думать о них, а не о том, по сколько транзакций открывать в одном соединении. Грамотная платформа обязана изолировать разработчика от этих кишочков, причем достаточно безболезненно. В том смысле, чтобы это не достигалось ценой, к примеру, просада производительности или ограничениями масштабируемости.

A>Вот кстати еще одна в которой неудобно использовать одну транзакцию:
A>Есть таблица в которой присутствуют записи должные быть распечатанными один единственный раз на некоторых принтерах (не будем вдаваться в каких, не суть важно). Т.е. в данном конкретном случае мы имеем с одной стороны БД целостность которой должны быть поддержана в любых условиях. С другой стороны повторная печать на принтере не допускается. Т.е. из этой таблицы данные должны удаляться (помечаться на удаление) после печати. Если я стартую все в одной транзакции, то мне туда же надо и запихивать удаление (пометку на удаление), и коммитить после каждой печати запрос на выборку. Ну и как данную задачу решить с одной транзакцией?
Ниче не понял. А в чем, собственно, проблема? Я четко вижу ровно одну транзакцию — выгрести и убить. Причем именно так: если выгребание по какой-то причине не удалось, то убивать нельзя, т.к. данные так и не доехали до принтера.
A>Легко скажете? А не легче ли стартовать snapshot транзакцию и не париться? Зачем лишний геморой? Я наверное не понимаю.
А чем вам поможет snapshot транзакция? Покажите мне, что делается в первой транзакции, и что во второй.

A>Вау. Бог и иже с ним. Я свою позицию по этому вопросы высказал. Проблема в том что Вы не хотите встать на позицию оппонента. Мне вас по человечески жаль.
Я на позиции оппонента уже стоял. Давно. По неведению.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

A>>То что у меня на одной форме два запроса работающих в разных транзакциях (причем один селект, а другой на апдейт к примеру), то где тут сырые данные скажите мне?
A>>Первый возвращает гарантировано закоммиченные данные
S>Кто тебе сказал? Вот тебе простой сценарий:
S>T1:
S>

S>update table1 set data = data + 100 where ID = 1
S>select data from table1 where ID=1
S>

S>Вот мы вроде бы почитали данные в транзакции 1. Допустим, получилось 150.
S>И тут же, не дожидаясь коммита, в совершенно другой транзакции мы пишем
S>

S>update table2 set data = 150 where id=1
S>

S>вот эти 150 — это сырые данные. Семантика запроса вроде бы такая ж, как если бы мы напрямую написали
S>

S>update table2 set data = (select data from table1 where id=1) where id=1
S>

S>Но в таком раскладе нам СУБД не даст выстрелить себе в ногу. В зависимости от архитектуры сервера и выбранного уровня изоляции такой апдейт либо заблокируется в ожидании коммита T1, либо скопирует "старое" значение из table1. В итоге, всё останется согласованным.

Этот пример показывает, что ACID сервер нарушить не даст.
Я может быть не совсем правильный пример привел. Но его идея была в том, что бы не делая коммита T1 видеть изменения, привенесённые T2. И все в рамках одного коннекта из одного потока.
Зачем это нужно — вопрос клиентского приложения.

A>>Вот кстати еще одна в которой неудобно использовать одну транзакцию:
A>>Есть таблица в которой присутствуют записи должные быть распечатанными один единственный раз на некоторых принтерах (не будем вдаваться в каких, не суть важно). Т.е. в данном конкретном случае мы имеем с одной стороны БД целостность которой должны быть поддержана в любых условиях. С другой стороны повторная печать на принтере не допускается. Т.е. из этой таблицы данные должны удаляться (помечаться на удаление) после печати. Если я стартую все в одной транзакции, то мне туда же надо и запихивать удаление (пометку на удаление), и коммитить после каждой печати запрос на выборку. Ну и как данную задачу решить с одной транзакцией?
S>Ниче не понял. А в чем, собственно, проблема? Я четко вижу ровно одну транзакцию — выгрести и убить. Причем именно так: если выгребание по какой-то причине не удалось, то убивать нельзя, т.к. данные так и не доехали до принтера.
Немного не так. Выгрести, попробовать обновить в другой транзакии, а результат увидеть в транзации выгребания.

P.S. Всё это обсуждалось, не касаясь конкретной предметной области.

Для предметных областей было приведено как минимум два примера:
1. Добавление клиента (T2) для изменяемого документа (T1)
2. Ведение лога работы пользователя (работа в T1, лог в T2)

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SЗ>>Да хотя бы на это:
IB>И причем здесь "это"?
Как я понял, аргументов не будет?

IB>P. S.
IB>Никто тебя, кстати, не банил, не надо тут истерики устраивать и на публику работать.

Угу. Только вот почему-то в БД мессаги под моим аккаунтом не отправлялись, тогда как Test работал без проблем

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SM>> Я может быть не совсем правильный пример привел. Но его идея была в том, что бы не делая коммита T1 видеть изменения, привенесённые T2. И все в рамках одного коннекта из одного потока.
S>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.

SM>>Для предметных областей было приведено как минимум два примера:
SM>>1. Добавление клиента (T2) для изменяемого документа (T1)
S>Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.
Может быть как минимум две причины:
1. Не возможности открыть ещё одно соединение
2. Спроектированная архитектура приложения

SM>>2. Ведение лога работы пользователя (работа в T1, лог в T2)
S>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?
Глобально — ничему.
Локально — я так и не понял, а чем плохо всё это делать из одного соединения.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

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

S>>Здравствуйте, SmlMouse, Вы писали:
S>>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции не пересеклись по данным.
Вот этого я не понял.
Если можно, поподробней.

S>Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.
Это преимущественно вопрос архитектуры клиентских библиотек.
Для IB/FB/YA обычно вообще открывается одно соединение на всё время жизни приложения, поэтому следить за закрытием соединения нет необходимости.
Так же открытвается пару read-only r-c транзакций для всяких сервисных нужд и фетч-запросов.
Все остальные write транзакции обычно нужны для конкретных операций, вытекающих из бизнес-логики, и там вступают в силу совсем другие принципы.
Всё это я к чему написал: проблема согласования времени жизни транзакции с временем жизни коннекта — это как бы совсем не проблема.
По крайней мере при использовании IB-based с соответсвующей архитектурой доступа она настолько ничтожна, что обращать внимание на неё не стоит.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

S>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Если тут такие умные — можете подключиться к разработке сервера и продемонстрировать свою техническую подготовку в разработке супера третьей версии FB.
S>Ну, в свете присутствия линейки MS SQL мне догонять Редмонд лень

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

Но тем неменее. В Редмонде работают реальные люди, как в прочем и в борланде, и в команде FB. И я, в силу своего характера, очень хорошо понимаю что географическое положение не влияет на мозги. И в связи с этим, в свое время на форуме OSP.RU "послал накуй" Сергея Кузнецова, который я так понимаю гуру российкого общества баз данных. А может его "однофамильца". Прошло восемь с лихом лет — я своего мнения, по этому вопросу, не поменял.

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

S>>Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.
SM> Это преимущественно вопрос архитектуры клиентских библиотек.
SM> Для IB/FB/YA обычно вообще открывается одно соединение на всё время жизни приложения, поэтому следить за закрытием соединения нет необходимости.
Это плохо масштабируемая архитектура. С точки зрения сервера, эти соединения почти всё время простаивают. Тем не менее, ему нужно держать ресурсы, ассоциированные с каждым подключением. Именно из-за этого изобрели connection pooling.
Удержание соединения придумано не из-за Interbase, а из-за того, что сначала с ним работал только BDE, спроектированный для парадокса. Уже потом пришлось для решения очевидных проблем прикручивать все эти костыли.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Ты хочешь сказать, что борланд его от этого отучил? Я вот наблюдал IB 5.5, который стабильно жрал ровно 25% от четырехпроцессорной машины.
Давно. Одна из фич IB7. 2003(?), кажется год

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

Здравствуйте, 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,
прежде тем строить эфемерные теории?..

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

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

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

Твои утверждения:

SM>(2) меняет данные на основании фетча из (1).
IB:То есть (2) видит незафиксированные данные (1), и кто после этого читает по диагонали?

SM>Которые и называются "параллельными".
IB:Нет, они последовательные. Транзакция не может начаться, пока не зафиксируется предыдущая, если так понятнее.

SM> Так как в одном соединении в одно и то же время могут быть несколько активнывх транзакций.
IB:Нет в этом смысла. Нельзя так делать и не несет это никакой практической ценности, я уже усталписать почему.

В поддержку моих — код.
Теперь объясни мне, почему так как в коде — делать не правильно.

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

IB>Понятия не имею чтотам у тебя случилось, когда банят выдается совершенно конкретное сообщение.
Ну не знаю. Меня ещё ни разу не банили. А RSDN@Home выдает конкретное сообщение?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

AC>А может ты сперва ознакомишься с тем, что там и как в IB/FB, прежде тем строить эфемерные теории?..
Можно ссылочку на документацию FB, где сказано, что он выполняет мини откаты при RC, и как он это делает?

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

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

Иван, я не поленился залезть в спецификацию OLEDB и привести атрибуты, управляющие несколькими сессиями в "одном" подключении MSSQL. Кроме того, мы потестили 2000 и 2005 сервер и опубликовали увиденное. Нет, мне не лень. Но куда лезть-то? У ADO.NET я не припоминаю наличие методов для старта отдельной транзакции.

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

Как модератор, ты должен был предотвратить, а не способствовать этому отклонению

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

Тут вот народ предлагает взять навооружение твои приемы и отвечать в таком же духе. Типа "Ну и что?", "И?", "Данунах" и т.д.

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

Да нет, просто курили хорошую траву. Спецификация получилась нормальная. Проще чем для ActiveX-компонент с их километровыми интерфейсами. Но, скажем честно, не для средних мозгов. Ребята граммотно перечислили ну очень много режимов и определили направление развитие. В том числе и MSSQL.

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

Серверный курсоров у FB никогда не было. Но тем неменее — юзается до сих пор. MSSQL-ем для линкед-серверов. Даже в MSSQL 2005.

Для FB это дело приходится моделировать.

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

Гы. Да я и щас повторю свой наезд на MS. Только он не на сиквел — я про него явно написал "мне он неинтересен". А на OLEDB.NET.

Разница, полагаю, есть. Если хочешь — могу обосрать ATL.OLEDB. Как ты догадываешься моей квалификации хватит за глаза.

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

SM>В поддержку моих — код.
Каких именно?

SM>Теперь объясни мне, почему так как в коде — делать не правильно.
Я уже раз восемь объяснил.

SM>Ну не знаю. Меня ещё ни разу не банили. А RSDN@Home выдает конкретное сообщение?
Забанят — узнаешь..

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

SM>>В поддержку моих — код.
IB>Каких именно?
Читай ветку. Хотя бы отсюда:
Re[11]: А может вообще уйти с Firebird?

SM>>Теперь объясни мне, почему так как в коде — делать не правильно.
IB>Я уже раз восемь объяснил.
Ссылку на объяснения в студию.

SM>>Ну не знаю. Меня ещё ни разу не банили. А RSDN@Home выдает конкретное сообщение?
IB>Забанят — узнаешь..

Хм. А я думал, у тебя уже есть опыт

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

SM> Читай ветку. Хотя бы отсюда:
SM> Re[11]: А может вообще уйти с Firebird?
Угу, а ты мои ответы, ровно на это.

SM> Ссылку на объяснения в студию.
http://rsdn.ru/forum/message/2664251.1.aspx

SM> Хм. А я думал, у тебя уже есть опыт

Я не нарываюсь..

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

КД>Иван, я не поленился залезть в спецификацию OLEDB и привести атрибуты, управляющие несколькими сессиями в "одном" подключении MSSQL.
Я ж тебе уже говорил, что OLEDB никакого отношения к MARS не имеет, там вообще другой провайдер.

КД>Но куда лезть-то?
в MARS.

КД>Как модератор, ты должен был предотвратить, а не способствовать этому отклонению

Ой, вот только не надо мне рассказывать про мои обязанности модератора.

КД> Если хочешь — могу обосрать ATL.OLEDB. Как ты догадываешься моей квалификации хватит за глаза.
Только с точки зрения внутренней реализации. Но вот с точки зрения архитектуры клиентских приложений — лучше не надо..

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

IB>Угу, а ты мои ответы, ровно на это.
SM>> Ссылку на объяснения в студию.
IB>http://rsdn.ru/forum/message/2664251.1.aspx

Твои ответы уводят в сторону.
Так как в них нет ни одного аргумента в пользу того, что моё утверждение не верно.

(hint)
— ACID для клиента ни к месту. Не будем же мы в самом деле забирать хлеб у сервера.
— "Транзакции" существуют на сервере. Соотвественно они не видят uncommited изменений друг друга.
— Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных.

P.S. Не дайте помереть в неведении.
Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

AC>Иван, IB/FB никогда ничего "втихаря" не делает.
Кто-то говорил, что FB что-то делает в тихаря?

AC>А речь свою веду о том, что ты не знаешь, какие "подуровни" RC существуют у IB/FB,
AC>но при этом заявляешь, что Oracle поступает правильнеееее

Ты опять меня не читаешь? Или искажаешь намеренно?
Я нигде не говорил, что Оракл поступает правильнее, я утверждаю, что у оракла RC строже. Чувствуешь разницу?

AC>PS: Документация у Кузьменко на сайте (ibase.ru)
Так конкретной ссылки не будет? Я вообщем-то так и думал.

AC>PPS: Умиляет твоя безапелляционность.
Меня умиляет ваша безграмотность и наивный троллизм.

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

КД>Мда. Я вот решил перечитать. Начальное сообщение.
КД>Короче парень, выпей йайду и убей себя об стену.
КД>Тебе никто не поможет.
КД>Думаю одна из причин в том что у ADO.NET нет интерфейса для поддержки "параллельных" транзакций. То есть типа это два противоречивых требования.
КД>Но если религия не мешает, можно соорудить свой .NET движок к серверу, который поддерживает несколько транзакций в одном подключении. Полагаю на роль последнего подходит только семейство IB-серверов

Ни пойдёть.
Тама есть всемогущий SYSDBA и ещё более всемогущий embeded, которому вообще по большому с высокой колокольни на права пользователей

Так что если базу того (сп*?:%) — то всё — оёк

Пару вариантов решения проблемы:
— взять исходники fb и прикрутить свои параметры в хидеры страниц, что бы стандартными сбоками такая база не подымалась.
— Связаться с Олегом (Лоа) Ивановым, на предмет дятла с возможностью шифрации самой БД.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

IB>Ну открой ты MSDN, если бы это было что-то не тривиальное я бы код написал, но если тебе лень в MSDN залезть, то извините...

интересно. когда на ibase.ru посылают — отмаз типа "лень смотреть или лень прямую ссылку искать". А в MSDN
абстрактно посылать — нормально?

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

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

не знаю. почему-то кажется.

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

позвольте. это наоборот, реализацию IB/FB пытаются представить как недостаток.

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

AC>>А может ты сперва ознакомишься с тем, что там и как в IB/FB, прежде тем строить эфемерные теории?..
IB>Можно ссылочку на документацию FB, где сказано, что он выполняет мини откаты при RC, и как он это делает?

В IB/FB нет ни миниоткатов ни мининакатов (мы не будем спускаться в недра сервера и говорить
о savepoint). Есть версионность. RC в ней можно сравнить хотя бы с RC реализуемом в версионности в MS SQL 2005,
к Ораклу переходить необязательно.

ссылочку на документацию можно,
www.ibase.ru/develop.htm
или www.ibase.ru/devinfo/ibtrans.htm
но Вам бы я посоветовал всю серию по версионности почитать, для начала
www.ibase.ru/devinfo/mga.htm

насчет "с миниоткатами строже". Речь, как я понимаю, об атомарности оператора
select? Атомарность эта в версионнике может быть достигнута переводом
параметров транзакции с RC до SNAPSHOT на время вычитки записей запроса.
Зачем тут делать "микрооткаты", как и вообще "микрооткаты" непонятно чего,
если Оракл "тоже версионник — неясно. Может объясните?

например я тут ни про какие "миниоткаты" или про особенную специфику Оракла в RC не увидел.

http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html

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

КДВ>интересно. когда на ibase.ru посылают — отмаз типа "лень смотреть или лень прямую ссылку искать". А в MSDN абстрактно посылать — нормально?

И этот дом еще борется за звание «Дома высокой культуры быта» (с)?

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

A>>Вот кстати еще одна в которой неудобно использовать одну транзакцию:
A>>Есть таблица в которой присутствуют записи должные быть распечатанными один единственный раз на некоторых принтерах (не будем вдаваться в каких, не суть важно). Т.е. в данном конкретном случае мы имеем с одной стороны БД целостность которой должны быть поддержана в любых условиях. С другой стороны повторная печать на принтере не допускается. Т.е. из этой таблицы данные должны удаляться (помечаться на удаление) после печати. Если я стартую все в одной транзакции, то мне туда же надо и запихивать удаление (пометку на удаление), и коммитить после каждой печати запрос на выборку. Ну и как данную задачу решить с одной транзакцией?
S>Ниче не понял. А в чем, собственно, проблема? Я четко вижу ровно одну транзакцию — выгрести и убить. Причем именно так: если выгребание по какой-то причине не удалось, то убивать нельзя, т.к. данные так и не доехали до принтера.

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

A>>Легко скажете? А не легче ли стартовать snapshot транзакцию и не париться? Зачем лишний геморой? Я наверное не понимаю.
S>А чем вам поможет snapshot транзакция? Покажите мне, что делается в первой транзакции, и что во второй.
1. select bla-bla-bla from table
2. delete from table where id=:id
С таблицей однозначно делаются только операции вставки и удаления. Причем некоторые записи должны быть напечатаны в одном пакете, и если произошла хоть одна ошибка при печати то откатить весь пакет и соответственно пропечатать отмену печати при необходимости. Первая читающая транзакция, можно сделать так что нагрузка сервера будем минимальна изначально (кстати, про такое Вы наверное не знаете?). Вторая чисто под удаления запускается. В чем порочен данный метод? Или мне надо делать два коннекта? Если нет, то лучше нагружать сервер откатами транзакций и иже с ним?

P.S. Можно конечно запускать запросы по одному, но по мне это достаточно геморный вариант. Хотя Вам виднее. Я был бы раз если мне предложат более простой способ для решения этой задачи.

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

SM>Я их очень внимательно читаю

Не заметно.. (

SM>Аргуметов, показывающих, что подход one-connection:many-transactions хуже one-connection:one-transaction я не вижу.
Я не вижу чем это хорошо.

SM>Ты правда считаешь, что такая ситуация в рамках моего примера не возможна в модели one-connection:one-transaction?
Все-таки не внимательно читаешь, или не читаешь вообще.

SM> Реализовывать логику сервера на клиенте задача лишняя и неблагодарная.
О чем и речь.

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

КДВ>не знаю. почему-то кажется.
Может быть еще что-нибудь кажется?

КДВ>позвольте. это наоборот, реализацию IB/FB пытаются представить как недостаток.
Посмотри с чего все началось.

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

КДВ>интересно. когда на ibase.ru посылают — отмаз типа "лень смотреть или лень прямую ссылку искать". А в MSDN
КДВ>абстрактно посылать — нормально?
В MSDN известна конкретная статья. Ровно тогоже я жду и от вас. К тому же ibase.ru, прямо скажем, не microsoft.com

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

КДВ>В IB/FB нет ни миниоткатов ни мининакатов (мы не будем спускаться в недра сервера и говорить
КДВ>о savepoint).
О чем я собственно и говорил. В FB миниоткатов нет. Хотя кое-кто пытался весьма неуклюже обвинить в обратном...

КДВ> RC в ней можно сравнить хотя бы с RC реализуемом в версионности в MS SQL 2005,
КДВ>к Ораклу переходить необязательно.
К ораклу перешел не я. Было утверждение, что в FB RC накой же как в оракле. Так вот это не так, RC в оракле отличается от FB-шного.
Будешь спорить?

КДВ>но Вам бы я посоветовал всю серию по версионности почитать, для начала
Я бе тебе советовал не спорить со мной про версионность.

КДВ> Речь, как я понимаю, об атомарности оператора select?
Речь о различных реализациях уровня RC.

КДВ>Зачем тут делать "микрооткаты", как и вообще "микрооткаты" непонятно чего, если Оракл "тоже версионник — неясно.
Если не ясно, тогда не надо спорить.

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

SM>>Я их очень внимательно читаю

IB>Не заметно.. (

Наша тема хороша, начинай сначала.
Хорошо. Ответь на простой вопрос.
В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку):

tr1->start; statement stm_tr1(tr1);
tr2->start; statement stm_tr2(tr2);
stm_tr1->Fetch; // SELECT field1, field2 from table1; // returned 1, test
stm_tr2->update; // update table1 set field2=updated where field1 = 1
tr2->commit;
stm_tr1->Fetch; // SELECT field1, field2 from table1; // returned 1, updated
tr1->commit;

SM>>Аргуметов, показывающих, что подход one-connection:many-transactions хуже one-connection:one-transaction я не вижу.
IB>Я не вижу чем это хорошо.
Этот агрумент говорит только о зрении смотрящего.
О недостатках/достоинствах самих подхов one-connection:many-transactions/one-connection:one-transaction этот аргумент не говорит ничего.
Изначально ты высказывался более определённо:

КДВ> Есть коннект. в его рамках можно одновременно стартовать несколько транзакций.
Вот это уже не логично.

Что изменилось с тех времён?

Да, логика — это такая научная дисциплина.
И раз уж ты говоришь, что утверждение не логично, то принято приводить доказательство.
Ну и заодно, вдруг не знаешь:

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

SM>>Ты правда считаешь, что такая ситуация в рамках моего примера не возможна в модели one-connection:one-transaction?
IB>Все-таки не внимательно читаешь, или не читаешь вообще.
Это нужно понимать как "ситауция возможна в обоих случаях" или "ситуация не возможна в one-connection:one-transaction" ?

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

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

КДВ>>интересно. когда на ibase.ru посылают — отмаз типа "лень смотреть или лень прямую ссылку искать". А в MSDN
КДВ>>абстрактно посылать — нормально?
IB>В MSDN известна конкретная статья.

мне пока не известна. и ссылок на msdn по теме разговора я пока ни одной не видел.

IB>Ровно тогоже я жду и от вас. К тому же ibase.ru, прямо скажем, не microsoft.com

допустим, не микрософт. однако, пока что Borland не уличил меня в некорректности
информации на ibase.ru. Информация по версионности на ibase.ru есть и ОТ АВТОРОВ IB.
И от авторов FB.

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

SM>Наша тема хороша, начинай сначала.
SM>Хорошо. Ответь на простой вопрос.
SM>В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку):
В данном коде tr1 видит данные которые появились в базе после того как началась tr1.
Те нарушена изоляция.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

КДВ>мне пока не известна. и ссылок на msdn по теме разговора я пока ни одной не видел.
Гугль в помощь...
http://www.google.ru/search?hl=ru&newwindow=1&q=site%3Amsdn2.microsoft.com+MARS&lr=

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

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

КДВ>>мне пока не известна. и ссылок на msdn по теме разговора я пока ни одной не видел.
WH>Гугль в помощь...
WH>http://www.google.ru/search?hl=ru&newwindow=1&q=site%3Amsdn2.microsoft.com+MARS&lr=

Ну и? Видим только упоминания о том что в рамках одной транзакции может существовать несколько активных множеств.

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

Я не нашел

Уж чего проще для людей, которые на ты с MSQL 2005 — затестите самостоятельно. Поверим на слово!

Уже четвертый день одно только бе и ме.

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

SM>> Если я добавлю, что tr1 стартанута в режиме RC, вы останетесь на своем мнении?

WH>Да.
WH>Более того я предвидел то что ты начнешь говорить про уровни изоляции.

Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()

WH>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний.
Вот так. ANSI стандарт уже нам не нужен?

WH>Все остальное это соглашения с конкретной реализацией базы данных о том что ты не должен делать для того чтобы транзакция осталась сериализованной.
Да? То есть нужно обязательно работать только в SR IL? А RC (кста, по моему в MSSQL это умолчательный IL) — от лукавого?

WH>Если ты сознательно нарушаешь соглашения, то ты сам себе злобный Буратино.
Какие именно? Если можно, опишите подробно, где и что я нарушил?

WH>И уж темболие не стоит говорить что это правильный путь.
Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
А то у вас тут знаете ли очень любят голословные утверждения.
Так вот, согласно местным традициям заявляю: "Я иду правильным путём!"

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

КДВ>что такое "миниоткаты" — это новый термин?
Это слэнговое название особенности реализации RC в Оракле. В принципе, механизм действия я описал.

КДВ>или это внутренний savepoint, который ЕСТЬ в IB/FB?
К сэйвпоинтам это не имеет никакого отношения.

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

КДВ>да ну?
Ну да.

КДВ> или версионность в MS SQL уже 23 года? Или Вы (ты) работаете(шь) с версионным сервером лет 12 ?
Причем тут MSSQL?

КДВ>В ЧЕМ ОНА ОТЛИЧАЕТСЯ. Прошу сообщить.
Я. уже. сообщил. Я даже не поленился алгоритм описать, правда без бодробностей. Может потрудишься прочитать?

КДВ>то есть, я умом не вышел?
Откуда я знаю, чем ты не вышел?

КДВ>Напрягитесь, пожалуйста, хоть один вменяемый аргумент дать.
Я вам вменяемых аргументов надавал — на полгода разбираться хватит.

КДВ>Я Вам уже кучу ссылок дал, а Вы все как-то по нулям.
Ссылки только что-то не конкретненькие, я тоже в MSDN послать могу, у меня не застрянет...

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

КДВ>а если мне надо читать одновременно и в TR2 и в TR1 ?
Что значит "одновременно"? Я еще раз объясняю: если у вас нет зависимостей по модификациям, то нет никакой разницы, одновременно вы это делаете или по очереди. Вам что, нужно определение сериализуемости процитировать? Простите, не верю.

КДВ>давайте не будем таким способом объяснять "ненужность" одновременно активных транзакций.
Хорошо, давайте объяснять нужность.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

SM>>> Если я добавлю, что tr1 стартанута в режиме RC, вы останетесь на своем мнении?

WH>>Да.
WH>>Более того я предвидел то что ты начнешь говорить про уровни изоляции.

SM> Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()

в что будет с твоей кислотностью, если после этого tr1 откатится? В твоем примере вызов commit tr1 не имеет смысла, т.к. в ней не сделано никаких изменений. Вот тебе модификация кода:

tr1->start; statement stm_tr1(tr1);
tr2->start; statement stm_tr2(tr2);
stm_tr1->Update; // Update table1 field1 set field1=1; // returned 1, test
stm_tr1->Fetch; // SELECT field1, field2 from table1; // returned 1, test
stm_tr2->update; // update table1 set field2=updated where field1 = 1
tr2->commit;
stm_tr1->Fetch; // SELECT field1, field2 from table1; // returned 1, updated
tr1->rollback;

WH>>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний.
SM> Вот так. ANSI стандарт уже нам не нужен?

При чем здесь ANSI стандарт? Есть жесткая математика, которая описывает что такое сериализуемость транзакций.
Есть еще более жесткая реальность, в которой гарантированное обеспечение этой сериализуемости обходится очень дорого. К примеру, любой селект должен приводить к блокировке не только отфетченных данных, но и предиката, причем блокировка должна удерживаться до конца транзакции. Поэтому разработчики СУБД придумали такую штуку, как "уровни изоляции". Уровень изоляции вовсе не означает "ослабленной изоляции", как может показаться наивным детям. Уровень изоляции — это договоренность о том, чего нельзя делать во время такой транзакции, чтобы сериализуемость по прежнему обеспечивалась.

WH>>Если ты сознательно нарушаешь соглашения, то ты сам себе злобный Буратино.
SM> Какие именно? Если можно, опишите подробно, где и что я нарушил?
Соглашения достаточно внятно описаны в уровнях изоляции. К примеру, в RC нельзя читать повторно те же данные. Иначе упорядоченность нарушится.
SM> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Tonal-, Вы писали:
IB>>Твоя просьба звучала именно так.
T>Хорошо, значит это ты не можешь аргументировать. Ок.

T>Можешь ли ты, привести ссылки на конкретные страницы/абзацы документации по любому серверу, где говорится о том, какое именно поведение клиента нарушает ACID гарантии сервера (здесь и здесь)?
1. В слове ACID мы рассматриваем букву I — isolation.
2. http://msdn2.microsoft.com/en-us/library/ms710099.aspx: "Ideally, transactions should be serializable".
3. http://msdn2.microsoft.com/en-us/library/ms709374.aspx
Наблюдаемые феномены нужно трактовать как запрещенные в данном уровне изоляции действия.

З.Ы. Иван компетентен, хоть и резковат.

... << RSDN@Home 1.2.0 alpha rev. 677>>

T>Хорошо, значит это ты не можешь аргументировать. Ок.
Аргументировать что? Твое неумение читать?

T>Можешь ли ты, привести ссылки на конкретные страницы/абзацы документации по любому серверу, где говорится о том, какое именно поведение клиента нарушает ACID гарантии сервера
Сколько раз тебе надо сказать, что я ни слова не говорил про гарантии сервера? С сервером все в порядке. Вы нарушаете требования изолированности транзакции на клиенте.
И тебе тот же вопрос, который вы все игнорируете — ты считаешь, что если требование изолированности нарушить на клиенте, то транзакция, в конечном итоге, станет более согласованной?

T>В том что ты не можешь привести не одной ссылки?
T>Или в том что ты некомпетентен в обсуждаемом вопросе?
И в том и в другом.

T>Значит, тебе следует научится выражатся яснее.
Возможно. Но пытаться что-то объяснить, ктогда тебя не хотят слушать занятие вообще бесполезное.

IB>>Впринципе это видно и без ссылок.
T>В общем-то да.
Рад, что ты это признаешь.. )

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

AC>Кем?
Чувством самосохранения и здравым смыслом.
AC>В указанных статьях ни слова о запретах.

Гм. Есть такая штука, как логика.
Например, есть феномен Ожог, возникающий при следующей последовательности действий:
1. Нагрев конфорки К1 до температуры 180С
2. Прикосновение ладони Л1 к конфорке К1

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

IB>>Я не вижу чем это хорошо.

SM>>Этот агрумент говорит только о зрении смотрящего.

IB>О! Запомни это. Отсюда я смело делаю вывод,
IB>что с вашим зрением что-то не то.

классика!
Иван, браво!
Продолжай так же.

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

SM>> Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!

IB>Для тупых похоже не получается.

+1

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

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

Редкостное угробище. Только чего мне стоили его глюки с инлайнингом

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

SM>>>> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
S>>>Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными.
SM>> Почему? Почему я _ВСЕГДА_ ею должен пользоваться?
S>Ну почему же всегда? Ты должен ей пользоваться только в тех жалких 99% случаев, когда нарушение целостности данных может привести к убыткам.
Применительно к моему примеру я не вижу нарушения целостности данных в БД.

S>

Феномен P1 может быть представлен как запрещение на следующую последовательность операций:

S>(2.1) w1[x]...r2[x]... (a1 и c2 в любом порядке)

S>(выделение моё).

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

Далее, давай не рвать из контекста, будет понятней:

Феномен P1 может быть представлен как запрещение на следующую последовательность операций:

(2.1) w1[x]...r2[x]... (a1 и c2 в любом порядке)

Словесное определение феномена P1 неоднозначно. Оно не настаивает на том, чтобы T1 заканчивалась откатом. Оно только утверждает, что если это произойдет, то может случиться что-то плохое. Некоторые люди интерпретируют P1 как:

(2.2) w1[x]...r2[x]... ((c1 или a1) и (c2 или a2) в любом порядке)

Запретив P1 в варианте (2.2), мы запретим любую историю следующего вида: T1 модифицирует содержимое элемента данных x. Затем T2 читает содержимое x, до того как T1 зафиксируется или откатится. Определение не настаивает на том, чтобы T1 откатилась или T2 зафиксировалась.

Так вот теперь посмотрим ещё раз на мой пример, и скажем, где же он нарывается на конфликт, согласно вышеприведенной цитате?
T1 у меня не изменяла данные. Соответственно w1[x] не происходило.
Немного объясню, почему: вышеприведенная цитата рассматривает вариант взаимодействия двух активных транзакций.
В моем примере повторное чтение происходит после того, как t2 закомитилась. То есть необходимого условия нет.

S>В идеале, СУБД должна принимать на выполнение сразу весь код транзакции, и автоматически выбирать уровень изоляции (а точнее, стратегию выполнения), обеспечивающую изоляцию для данного конкретного кода. Пока что (как и 15 лет назад) это утопия.

это сейчас не относится к делу.
напомню. речь шла о том, что две одновременно активные транзакции в одном соединение есть зло.
Пока мне никто так и не смог объяснить, в чём же это зло заключается.

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

Здравствуйте, Alex.Che, Вы писали:
AC>И снова слив! Восхитительно.

То есть дальше не осилил?
Как насчет http://emanual.ru/download/www.eManual.ru_538.html#part_4:

В стандарте ANSI SQL-92 [MS, ANSI] определяются четыре уровня изолированности.

1) Незафиксированное Чтение (READ UN-COMMITED).
2) Зафиксированное Чтение (READ COMMITED).
3) Повторимое Чтение (REPEATABLE READ).
4) Сериализуемость (SERIALIZABLE).

Они определяются с помощью классического определения сериализуемости и трех запрещенных последовательностей операций, названных феноменами: Грязное Чтение, Неповторимое Чтение и Фантом.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

Смешной вы, йуноша. Найди здесь FB:

http://tpc.org/tpch/results/tpch_perf_results.asp
http://www.tpc.org/tpce/tpce_perf_results.asp

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

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

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

здесь и ниже по ветке

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

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

___>Смешной вы, йуноша. Найди здесь FB:
___>http://tpc.org/tpch/results/tpch_perf_results.asp
___>http://www.tpc.org/tpce/tpce_perf_results.asp

О! Пионеры начали длиной мериться.

Ну-ну, продолжайте.
Ведь TCP, он именно для того чтоб пользовать "...пулинг кратковременно используемых соединений,
и трактовка базы как штуки, которую ты изредка беспокоишь своими просьбами что-то сделать."
Цирк снова с нами. Это радует.

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

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

___>>Редкостное угробище. Только чего мне стоили его глюки с инлайнингом

КД>Правда? Ой, а я и не знал

Спасибо! Вы открыли мне глаза

КД>Если хочешь поговорить о багах этого семейства компиляторов, о багах и проблемах VC — давай это сделаем в другой ветке. Думаю, это было бы забавно собрать в одном месте все мои сообщений по этой теме, которые я публиковал на форуме C++. Может кто еще что напишет полезное.

Мне уже не интересен BCB и его баги лет эдак 5. И C++ года этак 2.

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

___>Мне уже не интересен BCB и его баги лет эдак 5. И C++ года этак 2.

Ах, ну да. Простите, не в курсе ваших нынешних интересов

Но, полагаю, частично совпадают с моими — зарабатывать бабло и развлекаться на RSDN

Здравствуйте, Alex.Che, Вы писали:
AC>О! Пионеры начали длиной мериться.

AC>Ну-ну, продолжайте.
AC>Ведь TCP, он именно для того чтоб пользовать "...пулинг кратковременно используемых соединений,
AC>и трактовка базы как штуки, которую ты изредка беспокоишь своими просьбами что-то сделать."
AC>Цирк снова с нами. Это радует.
Лично меня радуют заявления о производительности чего-то, не подкрепленные какими-либо бенчмарками. В Success stores про 25 гигабайт и отличную работу в течение семи лет я конечно верю, но после каждой из них хочется откомментировать "а если бы у них был короткоствол, то всё сложилось бы иначе".

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Лично меня радуют заявления о производительности чего-то,
S>не подкрепленные какими-либо бенчмарками. В Success stores про 25 гигабайт
S>и отличную работу в течение семи лет я конечно верю, но после каждой из них
S>хочется откомментировать "а если бы у них был короткоствол, то всё сложилось бы иначе".

Если под наличием короткоствола подразумевать MS SQL, то таки, наверное застрелились бы...

(это я так, чисто ёрничаю, подражая Ивану )

Sinclair, ты ж вродь как взрослый человек, и в отличие от пионеров, знаешь(?),
какие условия нужно соблюсти, дабы опубликовать бенчмарки на TPC.
Знаешь так же и то, что FB — некоммерческий проект, который держится,
в основном, на энтузиазме разработчиков оного. Средств, дабы осуществить
официальное тестирование, нужно сперва где-то изыскать...
Что касается неофициального тестирования, то результаты были
опубликованы на sql.ru

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

S>Здравствуйте, Alex.Che, Вы писали:
S>Лично меня радуют заявления о производительности чего-то, не подкрепленные какими-либо бенчмарками. В Success stores про 25 гигабайт и отличную работу в течение семи лет я конечно верю, но после каждой из них хочется откомментировать "а если бы у них был короткоствол, то всё сложилось бы иначе".

Не, все не так. Я мог бы стать экспертом по спиртному. Щас бы спорил бы на других форумах на другие темы

Думаю там были бы похожие принципы, типа "чтобы понять надо бухать"

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

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

___>>Мне уже не интересен BCB и его баги лет эдак 5. И C++ года этак 2.

КД>Ах, ну да. Простите, не в курсе ваших нынешних интересов

Да ничего страшного. С кем не бывает.

КД>Но, полагаю, частично совпадают с моими — зарабатывать бабло и развлекаться на RSDN

Что-то вроде того.

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

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

S>>Лично меня радуют заявления о производительности чего-то,
S>>не подкрепленные какими-либо бенчмарками. В Success stores про 25 гигабайт
S>>и отличную работу в течение семи лет я конечно верю, но после каждой из них
S>>хочется откомментировать "а если бы у них был короткоствол, то всё сложилось бы иначе".

AC>Если под наличием короткоствола подразумевать MS SQL, то таки, наверное застрелились бы...

AC>(это я так, чисто ёрничаю, подражая Ивану )

Да Ивана как ... до Луны. Во всех смыслах. Тренироваться на кошечках.

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

AC>Sinclair, ты ж вродь как взрослый человек, и в отличие от пионеров, знаешь(?),какие условия нужно соблюсти, дабы опубликовать бенчмарки на TPC.
Конечно. Вот они: http://tpc.org/information/other/submit_results.asp. Что именно из этого не может FB?

AC>Знаешь так же и то, что FB — некоммерческий проект, который держится,
AC>в основном, на энтузиазме разработчиков оного. Средств, дабы осуществить
AC>официальное тестирование, нужно сперва где-то изыскать...
$1000 не получилось найти? Скинулись бы по десятке да засабмиттили...

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

AC>>Sinclair, ты ж вродь как взрослый человек, и в отличие от пионеров, знаешь(?),какие условия нужно соблюсти, дабы опубликовать бенчмарки на TPC.
S>Конечно. Вот они: http://tpc.org/information/other/submit_results.asp. Что именно из этого не может FB?

AC>>Знаешь так же и то, что FB — некоммерческий проект, который держится,
AC>>в основном, на энтузиазме разработчиков оного. Средств, дабы осуществить
AC>>официальное тестирование, нужно сперва где-то изыскать...
S>$1000 не получилось найти? Скинулись бы по десятке да засабмиттили...

Ага, было бы желание. Я бы сам лично червонец послал. А то и целых два.

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

S>$1000 не получилось найти? Скинулись бы по десятке да засабмиттили...

А зачем?
Когда Oracle с IBM меряются, оно понятно, речь идёт о рынке и баблосах.
А для FreeWare это зачем?
Повторяю, неофициальные тесты опубликованы. Выводы сделаны.

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

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

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

Например для меня:
— Загрузка данных из справочников по первому требованию.
— Периодическая запись накопившихся данных в информационный лог из другого потока.

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

AC>>в основном, на энтузиазме разработчиков оного. Средств, дабы осуществить
AC>>официальное тестирование, нужно сперва где-то изыскать...
S>$1000 не получилось найти? Скинулись бы по десятке да засабмиттили...

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

Например, по оригинальному вопросу этого топика — куда бы предложил засунуть
автор вопроса отсылку на tpc.org ?

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

КДВ>Поэтому tpc.org не является определяющим критерием при выборе сервера, да и собственно,
КДВ>важность этого критерия стоит где-то на десятом месте после остальной специфики.

КДВ>Например, по оригинальному вопросу этого топика — куда бы предложил засунуть
КДВ>автор вопроса отсылку на tpc.org ?

В MSDN

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

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

A>> но записи надо печатать по одной или более, на одном или более принтерах, причем сбойнуть может любой принтер в любой момент, а остальные должны продолжать печатать. Т.е. если я работаю в одной транзакции то должен после каждой делать коммит вместо того чтобы в данном случае просто сделать откат обновляющей транзакции? Я правильно понимаю?
S>Конечно. Я не понимаю, каким образом тебе поможет откат обновляющей транзакции.
Отменой удаления и поможет. Это что — непонятно? А на принтере отмену напечатать вообще в 5 секунд.

A>>С таблицей однозначно делаются только операции вставки и удаления. Причем некоторые записи должны быть напечатаны в одном пакете, и если произошла хоть одна ошибка при печати то откатить весь пакет и соответственно пропечатать отмену печати при необходимости.
S>То, что печатается пакетом, делается в одной транзакции.
В той же которая читает? Т.е. после каждого пакета мне надо коммитить читающую транзакцию и запускать новую практически? А если посмотреть на мое решение, то там печать тоже делается в одной транзакции.

A>>Первая читающая транзакция, можно сделать так что нагрузка сервера будем минимальна изначально (кстати, про такое Вы наверное не знаете?).
S>Может, и не знаю. Пока что я вообще не могу понять, чего хочется получить.
Требуемую распечатку в ЕДИНСТВЕННОМ экземпляре. Все очень просто. Задача специфическая для любых кафе в данном случае.

A>>Вторая чисто под удаления запускается. В чем порочен данный метод? Или мне надо делать два коннекта?
S>Удобнее всего делать столько коннектов, сколько принтеров.
Интересно. Я не против завести море коннектов, но если сервер мне позволяет все сделать в одном коннекте и это не противоречит ACID, то на кой мне париться?

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

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

___>здесь и ниже по ветке

Причем тут это сообщение. Там все тоже самое... омм мане падме хум... зачем параллельная транзакция, когда можно создать подключение? Ну вот, я говорю, есть у меня уже подключение, есть. Я могу в этом подключении создать новую транзакцию, и результат работы будет таким же. Ну вот блин зачем мне новое подключение создавать? Зачем? Можно на этот вопрос внятно ответить?

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

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

S>1) Незафиксированное Чтение (READ UN-COMMITED).
S>2) Зафиксированное Чтение (READ COMMITED).
S>3) Повторимое Чтение (REPEATABLE READ).
S>4) Сериализуемость (SERIALIZABLE).

S>Они определяются с помощью классического определения сериализуемости и трех запрещенных последовательностей операций, названных феноменами: Грязное Чтение, Неповторимое Чтение и Фантом.
S>[/q]

и? статья-то о том, что
а) данных уровней изолированности не хватает
б) базовые уровни изолированности ориентированы на блокировочные сервера
в) некоторые уровни изолированности описаны криво

все это не говорит о том, что единственно возможный применимый в реальной жизни уровень
изолированности транзакций — сериализация. Да, я согласен, некоторые задачи
решаются только сериализацией. Например, у меня на курсах примерно в 98 году был
мужик, который заявил:
— зачем вы об уровнях изолированности рассказываете? у нас все четко — вагон
пришел, попал под разгрузку, и ушел. Тут никаких конфликтов быть не может.

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

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

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

ссылкой на документ, в котором написано про миниоткаты в RC в Оракле.
я поискал на techdocs, ничего похожего не нашел.

КДВ>> или версионность в MS SQL уже 23 года? Или Вы (ты) работаете(шь) с версионным сервером лет 12 ?
IB>Причем тут MSSQL?

не знаю. Вы заявили, что Вы знаете версионность лучше меня. Я не нахожу причин
для такого утверждения. IB/FB Вы не знаете, а следовательно никак не можете
составить ПОЛНУЮ картину по реализации версионности в СУБД. Я напомню,
что в различных вариантах версионность есть в Oracle, InterBase/Firebird, MS SQL,
PostgreSQL и MS SQL 2005.

КДВ>>В ЧЕМ ОНА ОТЛИЧАЕТСЯ. Прошу сообщить.
IB>Я. уже. сообщил. Я даже не поленился алгоритм описать, правда без бодробностей. Может потрудишься прочитать?

"Оракл совершает миниоткат при обраружении измененных данных, читаемых в RC" — это "алгоритм"?
Это муть голубая.

КДВ>>Я Вам уже кучу ссылок дал, а Вы все как-то по нулям.
IB>Ссылки только что-то не конкретненькие, я тоже в MSDN послать могу, у меня не застрянет...

я про миниоткаты в Оракле спросил, MSDN мне без надобности.

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

IB>Сколько раз тебе надо сказать, что я ни слова не говорил про гарантии сервера? С сервером все в порядке. Вы нарушаете требования изолированности транзакции на клиенте.

Хм, а кто мне запретит абсолютно аналогичным способом "нарушать изолированность" использую 2 разных соединения?

Имея схему "один коннект — много транзакций" всегда можно применять ее как "один коннект — одна транзакция". Очевидно, что схему "один-коннект-много транзакций" применить как "один коннект — много транзакций" невозможно. Т.е. FB попросту более гибок. Когда подобная гибкость могла бы пригодиться... Навскидку, при ограничении числа одновременных коннектов(например купленных по лицензии) к БД.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Gt_>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...
Gt_>да и без поддержки smp ему там делать нечего. класик у которого даже кеша общего нет это не архитектура,
Gt_>а недорзумение.

Ну вот, уже и до создания одноразовых клонов дошли.
Верной дорогой идёте, товарищи!

Gt_>по Isolation levels — оракл на read commited обеспечивает консистентный набор (если не считать баг/фичу с минирестартами),
Gt_>IB и его клоны на IL read commited обеспечивают кашу в наборе, точно такую же какую обеспечивают блокировочники
Gt_>(имхо от того что каша соответствует стандарту мало чего меняется), поэтому считается что read commited оракла несколько выше.

Иван, так что там не так, с RC у FB, и почему у Oracle "выше"?

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

КД>Слушай я понял. Нам неправильно все объясняли. А мы не поняли где мы и с кем мы общались.
КД>- Две транзакции в одном подключении нельзя, потому что с каждого подключения можно срубить бабло.
КД>- Мы с тобой в магазине.
КД>- Объясняли нам менеджеры по продажам. Ну ты же их знаешь. Они же никогда не скажут — возьмите один ящик с двумя тюнерами. Скажут — возьми два(три, четыре) ящика. Вы же запутаесь, а тут все конкретно — вот он ящик, вот конкретная передача.

КД>Такие вот дела.
Нее. Всё гораздо хуже. Если представить менеджера по продажам как транзакцию, то в данной системе
мы смогли словить дедлок на единственной транзакции, которая сама себе наступила на хвост, а потом судорожными танцами вокруг да около, прихватывая всё что видит, попыталась из этого дедлока выскочить

Эх, жалко я теорию автоматов закинул... Там вроде дедлок можно было разрешить только внешним воздействием?
А мы видимо уже стали частью системы...

--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>

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

AC>>Повторяю, неофициальные тесты опубликованы. Выводы сделаны.

Gt_>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...

опять цирк. как раз по crash/recovery IB/FB тест пройдет. Потому что не надо "накатывать" или "откатывать"
логи. почитайте наконец, что-нибудь о версионных движках.

Gt_>да и без поддержки smp ему там делать нечего. класик у которого даже кеша общего нет это не архитектура, а недорзумение.

оставим и это.

Gt_>по Isolation levels — оракл на read commited обеспечивает консистентный набор (если не считать баг/фичу с минирестартами), IB и его клоны на IL read commited обеспечивают кашу в наборе, точно такую же какую обеспечивают блокировочники (имхо от того что каша соответствует стандарту мало чего меняется), поэтому считается что read commited оракла несколько выше.

поясните пожалуйста, про "кашу в наборе". Вы не это имеете в виду?
http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2

Gt_>к стате в новом OLTP тесте TPC-E mssql уже приходится в версионном режиме гонять.

Gt_>ЗЫ. на счет параллельных транзакций, постоянно юзаются в оракле: основная транзакция прежде чем выполнить действия регистрирует попытку действия в автономной транзакции (в том же конекте естественно) передая туда имя пользователя, код транзакции и прочую инфу из основной, после чего основная транзакция нарывается на какое-то исключение и благополучно откатывается, при этом попытка фиксируется автономной транзакцией. все происходит на сервере, естественно не нарушая никаких IL ... но доказать очевидное некоторым личностям вам не удастся

ахинея какая-то. "и эти люди запрещают нам ковыряться в носу"... Более дебильной реализации я не встречал.

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

___>>здесь и ниже по ветке

R>Причем тут это сообщение. Там все тоже самое... омм мане падме хум... зачем параллельная транзакция, когда можно создать подключение? Ну вот, я говорю, есть у меня уже подключение, есть. Я могу в этом подключении создать новую транзакцию, и результат работы будет таким же. Ну вот блин зачем мне новое подключение создавать? Зачем? Можно на этот вопрос внятно ответить?

точно такой же вопрос в ответ — если мне надо стартануть еще одну транзакцию — зачем мне
еще одно подключение создавать? зачем???
Вы понимаете, что подключение, обобщая и детализируя — это создание сокета, поиск в dns,
авторизация... Зачем делать это еще раз если соединение с сервером УЖЕ есть?

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

КДВ>Здравствуйте, Ramzzes, Вы писали:

___>>>здесь и ниже по ветке

R>>Причем тут это сообщение. Там все тоже самое... омм мане падме хум... зачем параллельная транзакция, когда можно создать подключение? Ну вот, я говорю, есть у меня уже подключение, есть. Я могу в этом подключении создать новую транзакцию, и результат работы будет таким же. Ну вот блин зачем мне новое подключение создавать? Зачем? Можно на этот вопрос внятно ответить?

КДВ>точно такой же вопрос в ответ — если мне надо стартануть еще одну транзакцию — зачем мне
КДВ>еще одно подключение создавать? зачем???
КДВ>Вы понимаете, что подключение, обобщая и детализируя — это создание сокета, поиск в dns,
КДВ>авторизация... Зачем делать это еще раз если соединение с сервером УЖЕ есть?

Так я вроде тоже самое написал... ?

Gt_>>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...

КДВ>опять цирк. как раз по crash/recovery IB/FB тест пройдет. Потому что не надо "накатывать" или "откатывать"
КДВ>логи. почитайте наконец, что-нибудь о версионных движках.

поверьте о версионности я вполне просвещен, а вот вы немного не вьезжаете о чем речь. попробуйте выдохнуть и неуподоблятся Мерле несущему ахинею. что такое лог транзакций вы думаю можете почитать в доке к последнему IB, там наконец его реализовали. применительно к tpc речь идет о простеньком тесте, вот например, что должен был пройти оракл в последнем tpc-c тесте:

Loss of Data
To demonstrate recovery from a permanent failure of durable medium containing TPC-C tables, the following steps were
executed:
1. A backup of the database was made.
2. The total number of New Orders was determined by the sum of D_NEXT_O_ID
of all rows in the DISTRICT table giving the beginning count. Consistency
check 3 was verified before run.
3. The RTE was started with 40500 users
4. The test was allowed to run for a minimum of 5 minutes.
5. Removed a disk from an array containing database data.
6. Oracle10g recorded errors about corrupt data on the partition. The database and
the RTE were then shut down.
7. The removed disk was replaced from the spares and the logical drives on that
array were restored from backup.
8. The database was then started. The database was recovered using the recover
command from SQLPLUS. The database was opened and Oracle 10g performed
instance recovery.
9. Consistency conditions were executed and verified.
10. Step 2 was repeated and the difference between the first and second counts was
noted.
11. An RTE report was generated for the entire run time giving the number of NEWORDERS
successfully returned to the RTE.
12. The counts in step 10 and 11 were compared and the results verified that all
committed transactions had been successfully recovered.
13. Samples were taken from the RTE files and used to query the database to
demonstrate successful transactions had corresponding rows in the ORDER
table.

http://www.tpc.org/results/FDR/TPCC/HP%20ML350G5_Oracle_070912_FDR.pdf
FB на 7 пункте бы закончил тест. да, про shadow и raid я в курсе ... тут не о них.

КДВ>поясните пожалуйста, про "кашу в наборе". Вы не это имеете в виду?
КДВ>http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2

да, это. оракл обеспечивает консистентный набор стейтмента на IL RC, т.е. в набор попадут только те записи какие были закомичены на момент старта стейтмента. у FB же RC гораздо слабее:

Теперь представим себе, что select читает данные, и уже начинает читать данные, которые обновлены другой транзакцией. пока вторая транзакция не committed, измененные версии записей игнорируются. Теперь вдруг обновляющая транзакция сделала commit. Читающая транзакция попадает на "вторую половину" обновлений, сделанных этой транзакцией. Но они уже committed, то есть их читать можно.
http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=173455&pg=2#1450276

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

ну они многим запрещают ... могут себе позволить

Gt_

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

SM>Эх, жалко я теорию автоматов закинул... Там вроде дедлок можно было разрешить только внешним воздействием?
SM>А мы видимо уже стали частью системы...

Вы уже давно стали частью файрберда, вы лишь его послушные роботы. Вас надо уничтожить.

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

КД>- Две транзакции в одном подключении нельзя, потому что с каждого подключения можно срубить бабло.

Если речь о лицензировании SQL Server, то одна лицензия на на пользователя подразумевает неограниченное кол-во подключений этого пользователя. Так шта опять мимо.

Здравствуйте, Andyshark, Вы писали:
S>>не догнал. Уж очень задача экзотическая.
A>Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей.
Послушай, то, что ты тут пишешь — поток сознания. Тебе может быть и понятно, кто там на ком стоял, но я до сих пор не вижу внятного объяснения, что собственно должно быть сделано. Это всё от того, что ты половину думаешь, а половину пишешь. При чем тут "проверка по таймеру"? Какое это отношение к транзакциям имеет? Я не понимаю, как ты откатом одной транзакции собираешься отменить часть напечатанных данных.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>>>не догнал. Уж очень задача экзотическая.
A>>Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей.
S>Послушай, то, что ты тут пишешь — поток сознания. Тебе может быть и понятно, кто там на ком стоял, но я до сих пор не вижу внятного объяснения, что собственно должно быть сделано. Это всё от того, что ты половину думаешь, а половину пишешь. При чем тут "проверка по таймеру"? Какое это отношение к транзакциям имеет? Я не понимаю, как ты откатом одной транзакции собираешься отменить часть напечатанных данных.

Tr.Rollback;
PrintString('Отмена печати');

Еще раз — печать идет пакетом. Если напечаталось две строки из пакета, но не напечаталась третья то надо сделать откат. А про таймер было написано к тому что записи может добавлять один компьютер, а печатать совсем другой. А мне влом проверку делать по таймеру просто (хотя и можно конечно). Но это к слову было сказано. Видно зря, вырвалось. Вырежи из контекста и обрати внимание на транзакции.
А запоминать какие строки были уже напечатаны и удалять их в этой же транзакции... Ну почему нельзя просто сразу сделать удаление, а в случае ошибки откатить транзакцию? Кстати, чем не 2 способа решения одной задачи?

P.S. Задача довольно специфическая. Но почему тут нельзя использовать 2 транзакции? Во всем посте слышно только одно — две транзакции в коннекте нельзя потому что нельзя... Помнится так же говорили и в средние века когда казнили еретиков. Хорошо тогда транзакций не было

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

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

SM>>Эх, жалко я теорию автоматов закинул... Там вроде дедлок можно было разрешить только внешним воздействием?
SM>>А мы видимо уже стали частью системы...

___>Вы уже давно стали частью файрберда, вы лишь его послушные роботы. Вас надо уничтожить.

Alex, ты где? Твой выстрел.

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

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

S>>>>не догнал. Уж очень задача экзотическая.
A>>>Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей.
S>>Послушай, то, что ты тут пишешь — поток сознания. Тебе может быть и понятно, кто там на ком стоял, но я до сих пор не вижу внятного объяснения, что собственно должно быть сделано. Это всё от того, что ты половину думаешь, а половину пишешь. При чем тут "проверка по таймеру"? Какое это отношение к транзакциям имеет? Я не понимаю, как ты откатом одной транзакции собираешься отменить часть напечатанных данных.

A>Tr.Rollback;
A>PrintString('Отмена печати');

A>Еще раз — печать идет пакетом. Если напечаталось две строки из пакета, но не напечаталась третья то надо сделать откат.
Совершенно верно. Непонятно мне ровно одно — зачем читать в одной, а удалять в другой?
Вот тебе код, который делает то, что нужно:

set transaction isolation level repeatable read
begin tran
select top 10 * from printQueue order by priority
-- здесь идет цикл выборки, и для каждой строки выполняем:
delete printQueue where id = 45
delete printQueue where id = 46
delete printQueue where id = 47
delete printQueue where id = 48
delete printQueue where id = 49

commit tran -- сюда мы попадаем если всё удалось

Если где-то произошла ошибка, то мы делаем rollback, и всё откатывается обратно.
A>А запоминать какие строки были уже напечатаны и удалять их в этой же транзакции...
Ничего не надо запоминать.
A>Ну почему нельзя просто сразу сделать удаление, а в случае ошибки откатить транзакцию? Кстати, чем не 2 способа решения одной задачи?
Можно. Код я привел.

A>P.S. Задача довольно специфическая. Но почему тут нельзя использовать 2 транзакции?
Потому, что не сработает. Ты же печатаешь на десяти принтерах, так? Откат "второй" транзакции откатит все пакеты. Должно быть столько транзакций, сколько принтеров.

... << RSDN@Home 1.2.0 alpha rev. 677>>

S>это способ сказать СУБД "не напрягайся, вот за этим я сам прослежу". В частности, если мы точно знаем, что в пределах транзакции происходит однократное чтение, то можно ее выполнять и на RC — сериализуемость не нарушится. Несмотря на более низкий уровень изоляции по сравнению с SERIALIZABLE.

Неверно, read committed не обеспечивает консистентный набор даже на уровне одного стейтмента, что совершенно не похоже на serializable.

Gt_

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

Gt_>да, это. оракл обеспечивает консистентный набор стейтмента на IL RC, т.е.
Gt_>в набор попадут только те записи какие были закомичены на момент старта стейтмента.
Gt_>у FB же RC гораздо слабее

Иван, и стоило создавать для этой ахинеии клона?

Повторяю, ты НИХРЕНА не знаешь о "подуровнях" RC в FB.
И продолжаешь нести...

AC>Иван, и стоило создавать для этой ахинеии клона?

я не пойму, это вы меня клоном Мерле пытаесь записать

вы тут совсем новенький что-ли ?

AC>Повторяю, ты НИХРЕНА не знаешь о "подуровнях" RC в FB.
AC>И продолжаешь нести...

походу как и в случае с логом транзакции вы не вьехали в термин consistency, если все таки осили то комбинацию параметров команды SET TRANSACTION которые обеспечат statement level consistency на read committed в студию ...

SP_>И это заявляет человек, первое сообщение которого датируется вчерашним днем

там наверху есть иконка поиск, не поверите он работает.
правда большинство постов Мерле сносил напрчь, но кое что из баталий во флейме уцелело:
http://www.rsdn.ru/Forum/?mid=559239

AC>

Вань, не стыдно?
AC>Хоть бы слова в предложениях переставлял...

это означает вы осилили термин consistency или мне еще стоит ждать комбинацию параметров для IBшного set transaction ?

ЗЫ. а в клоне тебя ничего не смущает ?
http://img.meta.ua/rsdnsearch/?page=1&mode=rank&q=Gt_

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

AC>>

Вань, не стыдно?
AC>>Хоть бы слова в предложениях переставлял...

Gt_>это означает вы осилили термин consistency или мне еще
Gt_>стоит ждать комбинацию параметров для IBшного set transaction ?

цирк продолжается...
Ню-ню, упорствуй, упорствуй...
Иван, ты сперва почитай таки доку, ссылку на которую
тебе дали, а потом приходи, будем обсуждать нюансы
IL RC в FB, и его отличия от Oracle с его "миниоткатами".
До тех пор, пока не прочитаешь и не скажешь:
"Ааааа, так ты имеешь в виду ЭТО...", — разговора не получится.
Дерзай.

ЗЫ: и не нужно меня брать "на слабо"

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

SP_>>И это заявляет человек, первое сообщение которого датируется вчерашним днем

Gt_>там наверху есть иконка поиск, не поверите он работает.
Gt_>правда большинство постов Мерле сносил напрчь, но кое что из баталий во флейме уцелело:
Gt_>http://www.rsdn.ru/Forum/?mid=559239

По линке баталия Merle с анонимом. Какое вы имеете к той баталии отношение —

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

SP_>По линке баталия Merle с анонимом. Какое вы имеете к той баталии отношение —

См последнюю строчку в постах анонима...
Почему он зарегистрировался только сейчас вопрос к Gt_

... << RSDN@Home 1.2.0 alpha rev. 745>>

WH>См последнюю строчку в постах анонима...
WH>Почему он зарегистрировался только сейчас вопрос к Gt_

потому что анонимные постинги в разделе "священные войны" запрещены ...

Gt_

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

Gt_>>>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...

КДВ>>опять цирк. как раз по crash/recovery IB/FB тест пройдет. Потому что не надо "накатывать" или "откатывать"
КДВ>>логи. почитайте наконец, что-нибудь о версионных движках.

Gt_>поверьте о версионности я вполне просвещен, а вот вы немного не вьезжаете о чем речь. попробуйте выдохнуть и неуподоблятся Мерле несущему ахинею. что такое лог транзакций вы думаю можете почитать в доке к последнему IB, там наконец его реализовали. применительно к tpc речь идет о простеньком тесте, вот например, что должен был пройти оракл в последнем tpc-c тесте:

нет, это Вы несете ахинею. потому что я в курсе, что такое transaction log, и потому,
что в IB 2007 реализован не transaction log, а журнал, т.е. write ahead log. И он страничный.
И вообще не для того, о чем Вы подумали.

Gt_>5. Removed a disk from an array containing database data.

тут я не знаю, что сказать, потому что из данного описания неясно, что это
за диск.

Gt_>7. The removed disk was replaced from the spares and the logical drives on that
Gt_>array were restored from backup.

тут непонятно, почему база осталась corrupted, если бэкап был восстановлен.

Gt_>http://www.tpc.org/results/FDR/TPCC/HP%20ML350G5_Oracle_070912_FDR.pdf
Gt_>FB на 7 пункте бы закончил тест. да, про shadow и raid я в курсе ... тут не о них.

я посмотрю.

КДВ>>поясните пожалуйста, про "кашу в наборе". Вы не это имеете в виду?
КДВ>>http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2

Gt_>да, это. оракл обеспечивает консистентный набор стейтмента на IL RC, т.е. в набор попадут только те записи какие были закомичены на момент старта стейтмента. у FB же RC гораздо слабее

если моя аргументация в том топике не катит, то...
и заметьте — в том топике это именно я объясняю про неатомарность select в RC в IB/FB, и
там же объясняю, почему это не так важно.

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

Gt_>это означает вы осилили термин consistency или мне еще стоит ждать комбинацию параметров для IBшного set transaction ?

например:
read write
consistency
nowait

или
read write
concurrency
nowait

оба случая — уровень изолированности snapshot.
по поводу стабильности курсора в RC в FB — лично я считаю что это ну никак не мешает понятию Read Committed.
в топике, который я упоминал, должны быть примеры, почему.

КДВ>например:
КДВ>read write
КДВ>consistency
КДВ>nowait

КДВ>или
КДВ>read write
КДВ>concurrency
КДВ>nowait

КДВ>оба случая — уровень изолированности snapshot.

и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )

КДВ>если моя аргументация в том топике не катит, то...
КДВ>и заметьте — в том топике это именно я объясняю про неатомарность select в RC в IB/FB, и
КДВ>там же объясняю, почему это не так важно.

аргументация чАго ? что RC в IB/FB способен получить консистентный набор ? что RC в oracle на это не способен ? я не понимаю что вы своей аргументацией хотите сказать ...

КДВ>по поводу стабильности курсора в RC в FB — лично я считаю что это ну никак не мешает понятию Read Committed.
КДВ>в топике, который я упоминал, должны быть примеры, почему.

не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?

КДВ>тут непонятно, почему база осталась corrupted, если бэкап был восстановлен.

бэкап делался до прогона теста, т.е. на него еще нужно накатить лог.

Gt_

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

КДВ>>например:
КДВ>>read write
КДВ>>consistency
КДВ>>nowait

КДВ>>или
КДВ>>read write
КДВ>>concurrency
КДВ>>nowait

КДВ>>оба случая — уровень изолированности snapshot.

Gt_>и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )

[ Осторожно, чтобы не было стыдно за сказанную глупость

]

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

В целом это не так и страшно. Неприятно, но не страшно. Потому что одним запросом, как правило, дело не обходится. А что бы второе множество было согласовано с первым — нужно повышать уровень изоляции.

Gt_>не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?

Зациклится. Не знаю как щас (и даже лень проверять) — но раньше циклил на ура

Вот. Но все это теоритические изыски (цель которых — попрыгать на известных багах сервера) и кои совершенно не мешают эксплуатации FB

КД>Выборка множества с уровнем изоляции read-commited вполне может вернуть записи, которые были "из вне" изменены и закоммичены после fetch. Это, да. Я даже помнится "бутылку пива" выиграл поэтому поводу ... в 99 году.

ну наконец-то, может вы сможете донести эту нехитрую мысль клиническому тормозу Alex.Che ? или там совсем клиника ?

КД>В целом это не так и страшно. Неприятно, но не страшно. Потому что одним запросом, как правило, дело не обходится. А что бы второе множество было согласовано с первым — нужно повышать уровень изоляции.

на сколько мне известно IB и его клоны это единственные из версионников которые на READ COMMITTED не способны получить консистентный набор: oracle, mysql/innodb, mssql/read_committed_snapshot зафетчат те строки какие находились на момент запроса, кладя болт на то что со строкаими произошло после запроса (вот про postgres не вкурсе).

КД>Зациклится. Не знаю как щас (и даже лень проверять) — но раньше циклил на ура

ну правильно. баг с cursor stability от уровня изолированости никак не зависит.

ЗЫ. разобравшись с read committed можем наконец вернутся к "Более дебильной реализации" которую вы "не встречал."

?

Gt_

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

КД>>Выборка множества с уровнем изоляции read-commited вполне может вернуть записи, которые были "из вне" изменены и закоммичены после fetch. Это, да. Я даже помнится "бутылку пива" выиграл поэтому поводу ... в 99 году.

Gt_>ну наконец-то, может вы сможете донести эту нехитрую мысль клиническому тормозу Alex.Che ? или там совсем клиника ?

Данунах (уж прости меня) — это не я и не он(?) начал все валить в одну кучу. Как я уже писал — мне всегда было ... на уровень изоляции read-commited.

Gt_>ЗЫ. разобравшись с read committed можем наконец вернутся к "Более дебильной реализации" которую вы "не встречал."

?

Это не ко мне

Все что я хотел узнать в этой ветке — так это про параллельные транзакции в одном коннекте

Но как только просил конкретных примеров — все прячутся

КД>Но как только просил конкретных примеров — все прячутся

да пожалуйте:

Using Autonomous Triggers

Among other things, you can use database triggers to log events transparently. Suppose you want to track all inserts into a table, even those that roll back. In Example 6-47, you use a trigger to insert duplicate rows into a shadow table. Because it is autonomous, the trigger can commit changes to the shadow table whether or not you commit changes to the main table.

Example 6-47 Using Autonomous Triggers

CREATE TABLE emp_audit ( emp_audit_id NUMBER(6), up_date DATE,
                         new_sal NUMBER(8,2), old_sal NUMBER(8,2) );

-- create an autonomous trigger that inserts into the audit table before
-- each update of salary in the employees table
CREATE OR REPLACE TRIGGER audit_sal
   BEFORE UPDATE OF salary ON employees FOR EACH ROW
DECLARE 
   PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  INSERT INTO emp_audit VALUES( :old.employee_id, SYSDATE, 
                                :new.salary, :old.salary );
  COMMIT;
END;
/
-- update the salary of an employee, and then commit the insert
UPDATE employees SET salary = salary * 1.05 WHERE employee_id = 115;
COMMIT;

-- update another salary, then roll back the update
UPDATE employees SET salary = salary * 1.05 WHERE employee_id = 116;
ROLLBACK;

-- show that both committed and rolled-back updates add rows to audit table
SELECT * FROM emp_audit WHERE emp_audit_id = 115 OR emp_audit_id = 116;

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

КД>>Но как только просил конкретных примеров — все прячутся

Gt_>да пожалуйте:

Gt_>Using Autonomous Triggers

Спасибо, но интересовали независимые транзакции на уровне клиента.

Я несколько раз описывал что именно. Последний раз Sinclair-у, кажется.

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

КДВ>>оба случая — уровень изолированности snapshot.

Gt_>и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )

snapshot конечно никакого отношения к делу не имеет. да, неконсистентный набор я называю неатомарным, что в принципе
одно и то же. Насчет возможности атомарного, или консистентного набора в RC, я не утверждаю, потому
что в IB/FB это невозможно. Вернее, возможно, с оговорками, и в случае когда в плане запроса
есть конструкция SORT.

Gt_>аргументация чАго ? что RC в IB/FB способен получить консистентный набор ? что RC в oracle на это не способен ? я не понимаю что вы своей аргументацией хотите сказать ...

типичное передергивание
а) я про Оракл ничего не хочу сказать. у него запросы консистентные в RC, и пусть
б) аргументацию я последовательно изложил в упомянутом топике на sql.ru
могу повторить еще раз. в IB/FB в уровне изолированности RC можно получить консистентный набор для Select
только если на время select перевести уровень изолированности в snapshot.
Надеюсь, понятно, почему? Если нет, отвечу — в IB/FB нет блокировок по чтению. есть версионность.
Также, сам по себе read committed предполагает нестабильность результатов отдельных select.
это стандартно. Следовательно, если разные select относительно друг друга нестабильны, то это
нормально. А если сам select нестабилен в RC — это ненормально? Так вот, ненормальность можно
исправить выполнением запроса в "микро-snapshot", если позволите такой термин.
Отсюда я делаю вывод, что подобная функциональность хоть и возможна, но не нужна.
Потому что RC не предназначен для "стабильности" как уровень изолированности non-repeatable read.

Gt_>не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?

понятно. то есть Вы, это еще один маньяк, который приколебался к этому пресловутому insert into select,
который в свою очередь к уровню изолированности никакого отношения не имеет, потому что выполняется
в одной транзакции, т.е. видит свои же данные. Как бороться с ЭТИМ — давно известно.
Фатальным это не является. считайте это implementation defined. И еще раз подчеркну — это
не относится к уровням изолированности транзакций вообще никаким боком.

КДВ>>тут непонятно, почему база осталась corrupted, если бэкап был восстановлен.

Gt_>бэкап делался до прогона теста, т.е. на него еще нужно накатить лог.

ну если так... А если выдернуть диск с логом? Впрочем, это уже обсуждали в "сравнении СУБД",
в отношении Оракла и MS SQL.
Относительно IB/FB могу сказать, что в них восстановить базу можно либо до уровня
последнего бэкапа, либо до уровня последнего инкрементного бэкапа в FB 2 или до уровня
последнего архивированного журнала в IB 2007. Что в принципе одно и то же.
И конечно, так как из лога журналов, здесь состояние базы не восстановить, ни в IB ни в FB.

От:	IB	http://rsdn.ru
Дата:	20.09.07 21:13
Оценка:	1 (1) +1 -3

	От:	_d_m_
	Дата:	21.09.07 04:31
	Оценка:	+2 -3

	От:	Eugeny__
	Дата:	08.10.07 10:12
	Оценка:	2 (2) +2

От:	IB	http://rsdn.ru
Дата:	23.09.07 10:36
Оценка:	1 (1) +1 -2

От:	IB	http://rsdn.ru
Дата:	20.09.07 22:21
Оценка:	+2 -2

	От:	AlexLinch
	Дата:	21.09.07 11:15
	Оценка:	5 (2) +1

От:	Кузьменко Д.В.	www.ibase.ru
Дата:	24.09.07 17:59
Оценка:	3 (1) +1 -1

От:	Коваленко Дмитрий	http://www.ibprovider.com
Дата:	23.09.07 18:34
Оценка:	2 (1) +2

	От:	Пацак
	Дата:	21.09.07 23:10
	Оценка:	+2 -1

От:	Tonal-	www.promsoft.ru
Дата:	23.09.07 07:52
Оценка:	+1 -2

От:	Sinclair	https://github.com/evilguest/
Дата:	24.09.07 09:11
Оценка:	+1 -2

От:	Ramzzes	http://ramzes.ws/
Дата:	21.09.07 10:59
Оценка:	+1 -1

	От:	Аноним
	Дата:	20.09.07 19:38
	Оценка:	1 (1)

	От:	Ромашка
	Дата:	19.09.07 09:53
	Оценка:	-1

	От:	SmlMouse Забанен
	Дата:	20.09.07 23:49
	Оценка: