Не пойму сути компонентов а-ля TTransaction

← →
pasha_golub © (2009-06-10 09:22) [0]

Вот тут общались с адептом Интербейз (файрберд) + FIBPlus и он мне тыкал: "мол, цыгане вы неразумные. У нас вот TpFIBTransaction. поназначал каждому query по транзакции и вперед в многопоточность. каждая qeury когда захотела и дергается к базе, а TpFIBTransaction рулит"

А я не пойму. Транзакция одна в контексте соединения, то есть TpFIBDatabase в данном случае. Это шо это получается, компонент TpFIBTransaction ставит в очередь все эти транзакции, или по надобности одну "резка" завершает, или как-то готовит активную для 2-хфазного коммита, или чего там происходит?

И для чего он вообще нужен? Почему я не могу работать прямо:
dbConnection.StartTransaction; try Query.Dances(); dbConnection.Commit(); except dbConnection.Rollback(); end;

буду признателен шибко. Ни с Файрбердом, ни с ФибПлюсом не работал, поэтому прошу сделать скидку.

← →
Sergey13 © (2009-06-10 09:33) [1]

> [0] pasha_golub © (10.06.09 09:22)
> Транзакция одна в контексте соединения

В случае с ФБ это не так. Их может быть много.

← →
Sergey Masloff (2009-06-10 09:51) [2]

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

← →
pasha_golub © (2009-06-10 10:18) [3]

> Sergey Masloff (10.06.09 09:51) [2]
>
> Паш, транзакции они сильно разные бывают. Ты когда делаешь
> dbConnection.Commit();
> делаешь это со "стандартным" набором свойств определяющим
> уровень изоляции. Часто эти "стандартные" очень отличаются
> от желаемых.

Да, это понимаемо. Но в пределах одного коннекта-то - одна активная транзакция.

> Sergey13 © (10.06.09 09:33) [1]

> В случае с ФБ это не так. Их может быть много.

О, как. А где можно прочитать? То есть там типа
START TRANSACTION <identifier> ?

← →
pasha_golub © (2009-06-10 10:22) [4]

← →
Sergey13 © (2009-06-10 11:14) [5]

> [3] pasha_golub © (10.06.09 10:18)
> О, как. А где можно прочитать?

Ну например у Ковязина в "Мир Интербейс". Или на http://ibase.ru/develop.htm

← →
pasha_golub © (2009-06-10 11:35) [6]

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

← →
test © (2009-06-10 11:43) [7]

А ты этого адепта сведи с адептом Оракл и готовься снимать на мобилу))

← →
pasha_golub © (2009-06-10 11:49) [8]

> test © (10.06.09 11:43) [7]
>
> А ты этого адепта сведи с адептом Оракл и готовься снимать
> на мобилу))

Не могу. :) В режиме переписки велся разговор.

← →
Sergey13 © (2009-06-10 11:59) [9]

> [6] pasha_golub © (10.06.09 11:35)

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

← →
jack128_ (2009-06-10 13:19) [10]

> Да, это понимаемо. Но в пределах одного коннекта-то - одна
> активная транзакция.
>

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

var
T1, T2: TIBTransaction;

begin
...
T1.Database := IBDatabase1;
T2.Database := IBDatabase1;
T1.StartTransaction;
T2.StartTransaction;

end;

> dbConnection.Execute("START TRANSACTION REPEATABLE READ");

такого в FB нету. По крайней мере в версиях <= 2.1
Все транзакции пускает клиент, скуль командой транзакцию нельзя запустить.

← →
Пит (2009-06-10 13:40) [11]

> Все транзакции пускает клиент, скуль командой транзакцию
> нельзя запустить.

хм, а какой еще командой можно запустить транзакцию?

Ведь команды SQL-серверу через установленное соединение идут в ТЕКСТОВОМ виде. Поэтому когда ты делаешь: StartTransaction, тем или иным способом клиент должен передать серверу команду начала транзакции.

Во многих случаях именно такой текст и передается аля: "START TRANSACTION" - это и есть команда на нативном уровне SQL-серверу.
То есть, вызов метода StartTransaction приводит к посылке серверу текста "START TRANSACTION".

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

Обычно разделение происходит на уровне TCP-сессий, все эти понятия старта транзакции, коммита, отката. А тут тогда как? Вот в чем вопрос - мне, кстати, тоже интересно. В рамках одного коннекта допустим передаются комманды:

START TRANSACTION ... UDATE ... ... START TRANSACTION ... COMMIT ... INSERT... ... SELECT ... ... ROLLBACK

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

← →
Sergey Masloff (2009-06-10 13:42) [12]

pasha_golub © (10.06.09 10:22) [4]

Допустим я это буду делать вручную:
dbConnection.Execute("START TRANSACTION REPEATABLE READ");
...

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

← →
Пит (2009-06-10 13:42) [13]

Поэтому Паша и говорит:

> О, как. А где можно прочитать? То есть там типа
> START TRANSACTION <identifier> ?

если реализовано имено так, то и очевидно каждое выражение должно идти с идентификатором, например:

START TRANSACTION <1>
INSERT... <1>
START TRANSACTION <2>
UPDATE... <2>
UPDATE ... <1>
COMMIT <1>
ROLLBACK <2>

← →
Sergey Masloff (2009-06-10 13:43) [14]

>Куча вопросов - как сервер отличит одну транзакцию от другой, какую закоммитили, какую откатили?
У каждой транзакции имеется уникальный идентификатор. Проблем отличать - никаких ;-)

← →
Пит (2009-06-10 13:48) [15]

> У каждой транзакции имеется уникальный идентификатор

ну вот о чем и спрашивается, то есть работает вариант описанный в [13]?

При каждом SELECT, INSERT, UPDATE, START/END TRANSACTION указывается идентификатор транзакции, придуманный клиентом? Видимо, AutoIncrement счетчик?

Я так понимаю вопрос об этом был.

← →
pasha_golub © (2009-06-10 13:52) [16]

> При каждом SELECT, INSERT, UPDATE, START/END TRANSACTION
> указывается идентификатор транзакции, придуманный клиентом?
>

ну где-то так

> Sergey Masloff (10.06.09 13:43) [14]

> У каждой транзакции имеется уникальный идентификатор. Проблем
> отличать - никаких ;-)

Проблем действительно никаких. КАК? :)

> Пенка TxxxTransaction в возможности "одновременно" иметь
> несколько открытых транзакций с разными уровнями изоляции.
> К многопоточности это отношения не имеет так как в потоке
> они все равно в одном.

Я понял суть. ТЕперь интересуют детали.

> Все транзакции пускает клиент, скуль командой транзакцию
> нельзя запустить.

Клиент как запускает? Шлет спец. пакеты?

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

И этот экземлпяр транзакции внутре делает .... что?

← →
Пит (2009-06-10 13:53) [17]

А.. Ну или более логичным было бы на:

START TRANSACTION

Отвечать аля:

TRANSACTION OK ID = XXX

← →
pasha_golub © (2009-06-10 13:54) [18]

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

← →
Пит (2009-06-10 13:57) [19]

> то мне достаточно для кверика личный датабейз прикрутить
> и пущай себе изолируется

ну это, видимо, дополнительные нагрузки - очередная аутентификация, поднятие коннекта и так далее...

Ну и в конце концов, возможно, идентификатор транзакции поддерживает бОльший диапазон, чем 1-65535. А именно таким будет теоретическое ограничение со стороны клиента при политике один коннект - одна транзакция )))

← →
Sergey Masloff (2009-06-10 13:58) [20]

Естественно таким текстом на сервер ничего не передается ;-)
У клиента есть свой API там все это делается. Выделяется буфер для параметров транзакции, заполняется, передается в соотв. API и после вызова имеем идентификатор транзакции в том числе.

Потом дескриптор этой транзакции используется в вызовах типа
isc_dsql_execute_immediate(status_vector, &db_handle, &trans_handle, 0, sql_str, 1, NULL);

где строка с SQL командой лишь один из множества параметров

← →
Sergey Masloff (2009-06-10 14:01) [21]

Sergey Masloff (10.06.09 13:58) [20]

Естественно о всем этом заморачиваться в 99.99999% случаев не нужно а достаточно кинуть комсспоненты TxxDatabase,TxxTransaction и TxxSql

Использовать много TxxDatabase для эмуляции такого поведения ПМСМ идеологически неправильно

← →
Пит (2009-06-10 14:32) [22]

> Естественно таким текстом на сервер ничего не передается
> ;-)

а ты уверен, смотрел? Ты говоришь про связку Application<->API (обычно в виде DLL). А я говорил про API<->Server, то есть то что непосредственно идет по каналу передачи на сервер SQL.

По-моему, в SQLite передается именно так, в текстовом виде. В DLL ты вызываешь аля:

sl_start_transaction(blabla)

А на сервер идет команда:

START TRANSACTION

Прямо так тупо в текстовом виде. Впрочем, это не говорил о том, что в Ib/FB, Oracle, MSSQL и прочем также. Но и обратное не доказывает )))

← →
pasha_golub © (2009-06-10 14:34) [23]

> У клиента есть свой API там все это делается.

Во как. Теперь ясно. Спасибо. А то я подумал, что отстал от течения жизни навеки.

А у кого еще разрешены множественные транзакции в контексте одного коннекта?

← →
pasha_golub © (2009-06-10 14:35) [24]

> Пит (10.06.09 14:32) [22]
>
>

SET TRANSACTION я увидел стейтмент в доке по Файрберду. Правда не знаю использовать его можно или это спец. вариант для внутренностей

← →
Пит (2009-06-10 14:43) [25]

> > У клиента есть свой API там все это делается.
>
> Во как. Теперь ясно. Спасибо

хм... Интересно... А ты до этого не знал, что к каждой БД обычно поставляется клиентская часть, выполненная в виде DLL?!

Например, у IB/FB она называется gds32.dll

Естественно, есть API взаимодействия с этой DLL, а точнее прототипы функций, экспортируемых из этой DLL. И есть API взаимодействия уже этой клиентской DLL с удаленным сервером по TCP или еще какому соединению.

Ну а компонент delphi уже облегчает работу с этой самой DLL. Связка:

TIBxxx компоненты -> gds32.dll -> IB Server

Как ты мог этого не знать.

← →
Игорь Шевченко © (2009-06-10 14:46) [26]

Пит (10.06.09 14:32) [22]

Про Oracle ради Аллаха не надо

← →
Пит (2009-06-10 15:00) [27]

Я ничего про Oracle и не утверждал.

← →
Игорь Шевченко © (2009-06-10 15:19) [28]

> А на сервер идет команда:
>
> START TRANSACTION
>
> Прямо так тупо в текстовом виде. Впрочем, это не говорил
> о том, что в Ib/FB, Oracle, MSSQL и прочем также. Но и обратное
> не доказывает )))

Вроде как ник тот же

← →
Пит (2009-06-10 15:24) [29]

А фразы:

>По-моему, в SQLite передается именно так

и специально уточняющую:

>Впрочем, это не говорит о том, что в Ib/FB, Oracle, MSSQL и прочем также

вы не учли?

Пит (10.06.09 15:24) [29]

Ты будешь цепляться пословно или побуквенно ?

← →
jack128_ (2009-06-10 15:42) [31]

> хм, а какой еще командой можно запустить транзакцию?
>
> Ведь команды SQL-серверу через установленное соединение
> идут в ТЕКСТОВОМ виде.

Какой ужас....

> Пит (10.06.09 14:43) [25]

>
> Как ты мог этого не знать.

Знал. И даже больше знал. :) Однако, не знал что АПИ напрямую трет с сервером о транзакциях. Для меня это дикость. Потому шо ANSI SQL предусматривает стейтмент для контроля за транзакциями.

> jack128_ (10.06.09 15:42) [31]

> Какой ужас....

Почему?

> Однако, не знал что АПИ напрямую трет с сервером о транзакциях

клиент с сервером завсегда терки устраивают в натуре

← →
Пит (2009-06-10 16:21) [35]

> Ты будешь цепляться пословно или побуквенно ?

Игорь, а вы перечитайте дискуссию.

Я говорил о том, что, ПО-МОЕМУ (насколько помню) в БД SQLite команды идут в текстовом виде. И прибавил, что в Oracle, IB, MSSQL я не знаю как, возможно по-другому.

Вы мне стали объяснять, что в Oracle не так, а потом еще и стали говорить, что я что-то утверждал про oracle. Ну и, кто придирается к словам?

> Однако, не знал что АПИ напрямую трет с сервером о транзакциях

ну ведь все общение идет через API, соответственно логично, что API трет с сервером о всех аспектах взаимодействия с БД.

Или ты имел в виду - думал, что управление транзакциями идет сквозняком через API командами SQL и сам API не знает о транзакциях? Ну наверное где-то так, где-то по иному.

> Игорь Шевченко © (10.06.09 15:51) [34]

> клиент с сервером завсегда терки устраивают в натуре

Я имею ввиду, что обениваются не SQL коммандами, а по спец. протоколу.

> ну ведь все общение идет через API

Я могу миновать АПИ и пулять все это по сокету, придерживаясь протокола.

> Или ты имел в виду - думал, что управление транзакциями
> идет сквозняком через API командами SQL и сам API не знает
> о транзакциях?

Примерно так. То есть АПИ может запросить сервер о состоянии транзакции, ее параметрах и т.п. Но тоже самое можно сделать через SQL, по крайней мере так в Постгресе реализовано.

← →
jack128_ (2009-06-10 17:20) [37]

> > jack128_ (10.06.09 15:42) [31]
>
>
> > Какой ужас....
>
> Почему?

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

В противном случае апи сервера состояло бы из одной функции
function ExecStmt(Stmt: string): string; {в строке результата - информация об ошибке}

В реальности этого не наблюдается..

> jack128_ (10.06.09 17:20) [37]

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

Нифига ж себе заявочки :)

А тебе программировать надо намагничиванием конкретных участков диска! Нет, блин, ты ведь ИДЕ используешь. Со строками йомайо :)

> В реальности этого не наблюдается..

Наблюдается. http://www.postgresql.org/docs/8.4/static/libpq-exec.html

Правда две функции. одна Exec, а вторая ExecParams. Но ведь вторую можно нафиг не использовать.

← →
jack128_ (2009-06-10 17:55) [39]

> А тебе программировать надо намагничиванием конкретных участков
> диска! Нет, блин, ты ведь ИДЕ используешь. Со строками йомайо
> :)

Поясни, где связь между намагничиванием конкретных участков диска, RAD и строгой типизацией параметров?

> В противном случае апи сервера состояло бы из одной функции
> function ExecStmt(Stmt: string): string; {в строке результата
> - информация об ошибке}

Собственно, так оно и есть. В большинстве случаев основные API - это Exec и Fetch, так как Exec должен откуда брать параметры в случае параметризованных запросов, добавляется Bind, так как Fetch должен куда-то класть то, что он нафетчил, добавляется Describe. Собственно, все.
Еще Connect и Disconnect.

Некоторые серверы реализуют отдельные вызовы управления транзакциями, типа BeginTransaction, Commit и Rollback, но это по большому счету излишне.
Говорю за те СУБД, с которыми более или менее знаком - Oracle, Interbase, ADABAS и за стандарт ODBC

Не пойму сути компонентов а-ля TTransaction Найти похожие ветки