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

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

P>>Пользователь начинает создание нового документа(пусть какая-то заявка). Одновременно с открытием формы стартуется транзакция Т1, которая будет АКТИВНА, читай незакомичена, все время, пока пользователь делает/редактирует документ. Версионная архитектура может себе позволить такие транзакции не сильно напрягаясь.
IB>Позволить можно все. Но напрягаться придется сильно.
Нет напряга. Вообще никакого.

P>>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2.
IB>T1 видит эти изменения?
После коммита T2?
Конечно.

P>>Так вот, подобный сценарий, в ФБ реализуется в рамках одного соединения, в то время как...
IB>То есть там дорого создавать коннекты и они нашли такой выход изположения — так?
На счет "дорого" единого ответа нет и быть не может.
Потому как для IB/FB есть несколько архитектур. На одной относительно дорого, на другой вообще ничего не стоит.
Вопрос в другом. В удобстве разработки и построения архитектуры приложения, используя данные возможности.
Так вот на текущий момент времени IB/FB располагает достаточной гибкостью в этом плане.

Здравствуйте, 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?

Автор: mmaxx
Дата: 19.09.07

Изначально человеку нужно ехать, а не шашечки. Как это "ехать" делается, с помощю дополнительного коннекшена или нет — дело десятое, тем более что на embedded один фиг все через shared memory гуляет на приличных серверах.

SM>Как то я аргументированных объяснений не увидел
Да я что-то даже не увидел на что тут можно аргументировано возразить...

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

SM> Нет напряга. Вообще никакого.
Вот я своими глазами видел как SAP-овское приложение, по такой схеме, кладет Оракл на 25-30 пользователях совершенно без напряга. Ну, ребята нашли простой выход, они на этот продукт больше 20 лицензий не продают... Вы так же поступаете?

IB>>T1 видит эти изменения?
SM> После коммита T2?
SM> Конечно.
Ты за него не отвечай, он сам справится.

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

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

Здравствуйте, 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?

Автор: mmaxx
Дата: 19.09.07

IB>Изначально человеку нужно ехать, а не шашечки. Как это "ехать" делается, с помощю дополнительного коннекшена или нет — дело десятое, тем более что на embedded один фиг все через shared memory гуляет на приличных серверах.
Человек про ехать сказал конкретно: параллельные транзакции.
Если ты не знаешь, что это такое, то это не значит, что человеку это не нужно.
Так що и это твое утверждение в лес.

SM>>Как то я аргументированных объяснений не увидел
IB>Да я что-то даже не увидел на что тут можно аргументировано возразить...
Мдя. Роман почти правильно увидел будущее...

P.S. Дальнейший разговор мне кажеться полностью бессмысленным.

Здравствуйте, 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>Ну правильно, освоили пулинг, появилась гибкость и человеческий подход, без изнурительных приседаний вокруг одного соединения.
Пуллинг чего? Коннектов?
Ну так его ещё и проектировать нужно под другие серваки.

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

SM>> Нет напряга. Вообще никакого.
IB>Вот я своими глазами видел как SAP-овское приложение, по такой схеме, кладет Оракл на 25-30 пользователях совершенно без напряга. Ну, ребята нашли простой выход, они на этот продукт больше 20 лицензий не продают... Вы так же поступаете?

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

IB>>>T1 видит эти изменения?
SM>> После коммита T2?
SM>> Конечно.
IB>Ты за него не отвечай, он сам справится.

Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился?
Только вот какое отношение это все имеет к поднятому вопросу?

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

Ну, тоже самое можно сказать и наоборот — вопрос привычки и наработанных решений, не так ли?

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

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

Здравствуйте, 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>Ты точно хорошо себе представляешь, как все на самом деле работает?

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

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

MZ>Господа, ваш спор беспочвенен.

MZ>У каких-то СУБД они совпадают все три, у каких-то
MZ>как-то разделены, это не имеет большого значения
MZ>и не влияет напрямую на производительность, при условии,
MZ>что все компоненты СУБД реализованы правильно.

так мы ж с этим не спорим. это наоборот, нам пытаются
доказать, что несколько транзакций на соединение не имеют смысла.
В MS SQL они может и не имеют смысла. Опять же, с этим не спорим.

MZ>Например, в IBase при коннекте может порождаться новый процесс ОС,

это только в классике. в супере — новый тред, или используется
имеющийся тред.

MZ>в Sybase ASE не порождается даже тред. Но это никак не связано
MZ>с реализацией или не реализацией парралельных транзакций.

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

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

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

КД>>Мда... Иван, иногда они возникают "сами по себе".
IB>Так будет сценарий или нет?

в IB/FB бэкап производится в транзакции snapshot.
как только стартанули бэкап — он стартовал транзакцию
и пошел читать данные и сохранять их. Никому это особо не мешает.

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

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

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

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

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

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

TR3.StartTransaction;

TR2.Commit.

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

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

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

Здравствуйте, 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". То есть, я в приложении могу прочитать запись в контексте одной транзакции,
КДВ>и на основании этих данных что-то сделать в другой транзакции.
КДВ>непонятно, почему тебе это непонятно.
Да хоть из разных приложений можно увидеть то что сделали в другом при условии что еще и коммит не сделали (Главное чтоб в транзакции произвели действия)- уровни изоляции транзакций никто не запрещал менять

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

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

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

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

КДВ>в IB/FB бэкап производится в транзакции snapshot.
Это проблемы IB

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

КДВ>не надо путать параллельное выполнение действий на сервере с действиями на клиенте.
Угу, не надо. Так кто тут про действия на сервере заговорил?

КДВ>Придумать такое — это ж надо...
Вот и я о том же.

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

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

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

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

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

P>Если я правильно понял то, о чем ты хотел сказать своим примером.
Нда.. не правильно.
Своим примером я хотел сказать, что даже для версионника длинные транзации- не сахар.

P>Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился?
Нет.

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

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

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

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

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

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

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

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

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

SM> Так що в лес.
Так, юноша. Встал, вышел и зашел как учили..

SM> И тебе пытались объяснить на примерах, как можно сделать.
Ты так и не понял, что тебе пытались объяснить почему так делать нельзя.

SM> И обрати внимание, кто тебе много и терпиливо объяснял в соседней подветке.
Пальцы тоже растопыривать не стоит, тем более чужие.
У IB-шников похоже просто комплекс какой-то.