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

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

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

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

Р>Бесплатные версии есть также у Оракла и ДБ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. А сейчас есть.
КДВ>Будут и "параллельные транзакции"

Мда... но я думаю у нас будет что еще обсудить и сравнить. Например — триггеры

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

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

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

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

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

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

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

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

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

КДВ>Ей-богу, ну не было раньше версионности в 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:
> Честно-честно?
> А пацаны то незнают:
> Многоверсионность данных и управление параллельными транзакциями

Пацаны много чего не знают.

SmlMouse wrote:
> Р>Это что-то в Firebird перемутили. Транзакции параллельными и
> Р>перпендикулярными быть не могут.
> Ну, с исторической точки зрения FireBird тут совсем ни при чем.
> "Перемутил" Джим в незапамятные времена.
> За что многие люди (и я) ему благодарны.
Гм... Он не задумывался анд тем, что вы так извратите его идеи.
>> > Embeded?
> Р>Нет.
> Это было одно из требований.
Это было с грифом "желательно".
>> > А поподробней, где почитать про всё это применительно к MS SQL?
> Р>BooksOnLine. Скачать мождно с сайта мелкомягких.
> Там ни слова про параллельные транзакции.
Как ты думаешь, почему?
> Р>ЗЫ. Бесплатные версии есть также у Оракла и ДБ2. Все не embedded.
> Не в одном из перечисленных нет того, что нужно:
> — несколько транзакций на сессию. тем более с разными уровнями изоляции
Сам понял что написал?
> — минимальные затраты на развёртывание (положил DLL в каталог продукта и
> все. Или еще проще — прилинковал либы в экзешник).
см. выше.
> — открытые исходники с возможностью модификации.
Это ты сам выдумал?

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

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

КД>Не перегибай палку
Я вообще с палками не очень...

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

КД>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.

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

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

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

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

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

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

--
With best regards, Alex Cherednichenko.

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

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

Мда... Иван, иногда они возникают "сами по себе".

У нас такое сплошь и рядом, когда начинают днем заливать в рабочую базу, на которой висит под сотню пользователей, пакеты репликации. Бывают пакеты маленькие (относительно короткие транзакции). Бывают достаточно большие — тут как повезет.

Или формировать пакеты репликации.

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