Здравствуйте, Ромашка, Вы писали:
>> Ну, с исторической точки зрения 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>Аналогичный вопрос: ты можешь показать, на пальцах, для тупых, чем это плохо?
Тем что расходуются ресурсы сервера.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Мда... Иван, иногда они возникают "сами по себе".
Так будет сценарий или нет?
КД>Если начнут посередине дня резервировать базу целиком — ну тоже часа полтора транзакция будет висеть. База-то немаленькая, хотя и работает на мега-коне.
Ну допустим (кхм..). И вот тот самый поток который заливает пакет репликации в одной транзакции, приостанавливает это дело и запускает другие транзакции, пока репликация курит?
Нда, и эти люди запрещают мне ковыряться в носу..
Привет, IB!
Вы пишешь 20 сентября 2007:
AC>> Аналогичный вопрос: ты можешь показать, на пальцах, для тупых, чем это плохо? I> Тем что расходуются ресурсы сервера.
Какого именно сервера, Иван?
Какие именно ресурсы?
И как соотносится сей "перерасход" с аналогичным,
но в случае "параллельного коннекта", а не транзакции?
Здравствуйте, SmlMouse, Вы писали:
SM>Походу имеется недопонимание.
Определенно.
SM>Параллельные != одновременно (синхронно) выполняющиеся в клиенте.
Уух.. параллельно — это асинхронно, синхронно — это последовательно.
SM>в (1) фетч данных SM>в (2) адейт записи, входящей в отфетченный набор из (1)
Транзакция обладает ACID-ностью. Буковка I — изолированность. На практике это означает, что транзакция (2) не может увидеть результат работы транзакции (1), до тех пор, пока (1) не зафиксировалась. Если позволить делать такие фокусы, то это приведет к эффекту Cascading Aborts — если ранзакция (2) зафиксируется, а транзакция (1) по каким-то причинам не сможет, то и (2) надо тоже откатывать. Более того, надо откатывать все транзакции, которые к этому времени успели попользоваться изменениями всесенными (2) — и далее по цепочке. Если этого не делать, то окажется что транзакция (2) зафиксировала данные, которые никогда не существовали.
SM> Например, ввод клиента в процессе ввода счёта.
Ввод клиента в процессе ввода счета — это несколько транзакций.
SM>Можно и в одной [транзакции], но замумукашься в боле-мене сложном структурно функционале отслеживать в каком состоянии SM>была единственная транзакция на входе в модуль и надо ли её коммитить на выходе
Вот это, кстати, не вопрос. как только пошло что-то не то, транзакцию надо откатывать.
SM> и как откатить изменения функции не откатывая изменений в вызвавшей её функции и во всех вызванных из неё ранее.
Так у нас транзакция или нет? Если транзакция, то надо откатывать все, безвопросов, елси не все, значит это несколько последовательных транзакций.
Здравствуйте, 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>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Понятно. А есть возможность вообще запретить неявный старт? 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>>
Господа, ваш спор беспочвенен.
Оба варианта взаимодействия клиента и сервера имеют
право на жизнь.
По сути при общении клиента и сервера используются
несколько контекстов
-- контекст для передачи данных между ними
-- контекст для управления транзакциями.
-- контекст для управления потоком выполнения комманд.
У каких-то СУБД они совпадают все три, у каких-то
как-то разделены, это не имеет большого значения
и не влияет напрямую на производительность, при условии,
что все компоненты СУБД реализованы правильно.
Как это влияет на производительность — зависит исключительно
от странностей конкретной СУБД, а не от выбранного подхода.
Например, в IBase при коннекте может порождаться новый процесс ОС,
в Sybase ASE не порождается даже тред. Но это никак не связано
с реализацией или не реализацией парралельных транзакций.
Здравствуйте, SmlMouse, Вы писали:
SM> (1) увидит изменения, привнесённые (2). Естественно после того, как (2) закомититься.
Так в чем тогда проблема стартовать (1) после того как (2) зафиксировалась?
SM>Ага. Но не несколько соединений.
Да байта ради. Но это несколько последовательных транзакций в одном соединении.
SM>А ввод нужного клиента
Что ввод клиента?
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД> И есть скрытое глобальное место, где таки хранятся готовые подключения. Называется пулом. Пулом подключений. Не можно, конечно, без пула — да ради бога — указываем "OLE DB Services=0" и вперед к тормозам
Ну, то есть в IB своего пула нет и поэтому они считают, что пихать в один коннект несколько транзакций это круто, я правильно понял?
КД>Мдаа... Берем тривиальную задачу — запись логического лога в базу данных.
Для записи лога есть 33 способа, не говоря уже о том, что писать лог практически в то же хранилище где лежат и основные данные не очень правильно.
КД>Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет.
То есть, две транзакции из одного потока могут видеть незакоммиченые данные друг-друга? Прости, но это уже не транзакции.
КД>Поэтому у этого протоколирующего объекта должна быть собственная (короткая) транзакция.
Угу, но она не должна видеть незакоммиченых данных основной.
КД>... Заявления что паралельные транзакции имееют смысл только в раздельных потоках очень похоже на требование работы с разными файлами исключительно в разных потоках.
Пока не привели ни одного сценария, где действительно необходимо приостанавливать действие одной транзакции и выполнять другую в том же потоке.
И таких сценариев нет. Объясню еще раз почему:
Единственный случай, когда это может потребоваться — это организовать обмен незафиксированными данными между двумя транзакциями в обход сервера. То есть, сервер нам это делать запрещает, а мы придумываем как это обойти. Почему сервер это запрещает — я писал.
Ребята, у вас нет ощущения что вы делаете что-то не то?
КД>... Иван, завязывай с линейным мышлением. На улице уже даже не объектно-ориентированное время. В один корпус кучу ядер интегрируют, а ты не можешь понять зачем несколько транзакций засовывают в одной трубе подключения.
Ты сам-то понимаешь, зачем это делаешь?
КД>В функции реализации старта транзакции, которая автоматически пороздает новое подключение.
Какая функция реализация старта? старт транзакции начинается с первого оператора.
КД>Я просил тебя написать простенький пример, который подтверждает возможность старта параллельной транзакции без открытия нового подключения. Слив как, защитывать?
MSDN открой.
КД>Иван, с тобой тяжко общаться...
Привыкай.
КД> Понимаешь, Firebird это сервер для людей у которых как-то более продвинутая способность к восприятию мира
Вот тут у меня серьезные сомнения. Я бы скорее использовал термин "измененное сознание".
КД> и они не возможности сервера натягивают на предметную область, а наоборот
Ну, нормальные люди предпочитают просто использовать адекватные инструменты, вместо того чтобы что-то на что-то натягивать.
Здравствуйте, 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'а.
Я уже ответил на этот пример.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Давай мы не будем отклоняться от основной темы.
Это собственно то, с чего начался разговор.
КД>Как там папа сказал в индонезии — единство в разнообразии.
Вот только причем тут разнообразие...
КД>С какого перепугу? Не выдавай желаемое за действительное.
Я не выдаю. Ты сам-то внимательно прочитал, что пишешь?
КД>Она и не видет. А зачем ей их видеть?
Чтобы записать в лог.
КД>Лично мне не кажется.
Хм, помоему самое время задуматься над этим..
КД>Конечно понимаю Я понимал это еще в прошлом веке.
Похоже пришло время переосмыслить..
КД>А что там внутри делается, мы значит описать не в состоянии?
Я уже устал описывать как, зачем и почему.
КД>Я так понял, вместо того чтобы пытаться разобраться и объяснить конкретные вещи,
Я тебе объяснил очень конкретные вещи. Я не виноват, что ты их игнорируешь.
Пример сценария, на пальцах и формочных примитивах, может так всем будет понятнее:
Пользователь начинает создание нового документа(пусть какая-то заявка). Одновременно с открытием формы стартуется транзакция Т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?
Здравствуйте, pnv82, Вы писали:
P>Пользователь начинает создание нового документа(пусть какая-то заявка). Одновременно с открытием формы стартуется транзакция Т1, которая будет АКТИВНА, читай незакомичена, все время, пока пользователь делает/редактирует документ. Версионная архитектура может себе позволить такие транзакции не сильно напрягаясь.
Позволить можно все. Но напрягаться придется сильно.
P>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2.
T1 видит эти изменения?
P>Так вот, подобный сценарий, в ФБ реализуется в рамках одного соединения, в то время как...
То есть там дорого создавать коннекты и они нашли такой выход изположения — так?
Мы уже победили, просто это еще не так заметно...
И на 2000 и на 2005
