Форум: "Прочее";
Текущий архив: 2009.08.16;
Скачать: [xml.tar.bz2];
ВнизНе пойму сути компонентов а-ля 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]
> Sergey Masloff (10.06.09 09:51) [2]
>
> Паш, транзакции они сильно разные бывают. Ты когда делаешь
> dbConnection.Commit();
> делаешь это со "стандартным" набором свойств определяющим
> уровень изоляции. Часто эти "стандартные" очень отличаются
> от желаемых.
Допустим я это буду делать вручную:dbConnection.Execute("START TRANSACTION REPEATABLE READ");
...
← →
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 и прочем также
вы не учли?
← →
Игорь Шевченко © (2009-06-10 15:32) [30]Пит (10.06.09 15:24) [29]
Ты будешь цепляться пословно или побуквенно ?
← →
jack128_ (2009-06-10 15:42) [31]
> хм, а какой еще командой можно запустить транзакцию?
>
> Ведь команды SQL-серверу через установленное соединение
> идут в ТЕКСТОВОМ виде.
Какой ужас....
← →
pasha_golub © (2009-06-10 15:44) [32]
> Пит (10.06.09 14:43) [25]
>
> Как ты мог этого не знать.
Знал. И даже больше знал. :) Однако, не знал что АПИ напрямую трет с сервером о транзакциях. Для меня это дикость. Потому шо ANSI SQL предусматривает стейтмент для контроля за транзакциями.
← →
pasha_golub © (2009-06-10 15:44) [33]
> jack128_ (10.06.09 15:42) [31]
> Какой ужас....
Почему?
← →
Игорь Шевченко © (2009-06-10 15:51) [34]
> Однако, не знал что АПИ напрямую трет с сервером о транзакциях
клиент с сервером завсегда терки устраивают в натуре
← →
Пит (2009-06-10 16:21) [35]
> Ты будешь цепляться пословно или побуквенно ?
Игорь, а вы перечитайте дискуссию.
Я говорил о том, что, ПО-МОЕМУ (насколько помню) в БД SQLite команды идут в текстовом виде. И прибавил, что в Oracle, IB, MSSQL я не знаю как, возможно по-другому.
Вы мне стали объяснять, что в Oracle не так, а потом еще и стали говорить, что я что-то утверждал про oracle. Ну и, кто придирается к словам?
> Однако, не знал что АПИ напрямую трет с сервером о транзакциях
ну ведь все общение идет через API, соответственно логично, что API трет с сервером о всех аспектах взаимодействия с БД.
Или ты имел в виду - думал, что управление транзакциями идет сквозняком через API командами SQL и сам API не знает о транзакциях? Ну наверное где-то так, где-то по иному.
← →
pasha_golub © (2009-06-10 16:28) [36]
> Игорь Шевченко © (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; {в строке результата - информация об ошибке}
В реальности этого не наблюдается..
← →
pasha_golub © (2009-06-10 17:36) [38]
> 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 и строгой типизацией параметров?
← →
Игорь Шевченко © (2009-06-10 17:56) [40]
> В противном случае апи сервера состояло бы из одной функции
> function ExecStmt(Stmt: string): string; {в строке результата
> - информация об ошибке}
Собственно, так оно и есть. В большинстве случаев основные API - это Exec и Fetch, так как Exec должен откуда брать параметры в случае параметризованных запросов, добавляется Bind, так как Fetch должен куда-то класть то, что он нафетчил, добавляется Describe. Собственно, все.
Еще Connect и Disconnect.
Некоторые серверы реализуют отдельные вызовы управления транзакциями, типа BeginTransaction, Commit и Rollback, но это по большому счету излишне.
Говорю за те СУБД, с которыми более или менее знаком - Oracle, Interbase, ADABAS и за стандарт ODBC
← →
Пит (2009-06-10 18:35) [41]
> по моему убеждению все параметры нуно отдавать в формальном
> виде
сразу видно адепта строго типизированных ЯВУ )))
А вот какой-нибудь PHP"шник высказался бы по-другому.
Текстовое общение имеет ряд преимуществ. Многие очень используемые современные протоколы имеют именно текст-основу: тот же HTTP.
Преимущества в наглядности и доступности, недостатки в неэффективности (постоянный парсинг) и избыточности данных. Но с таким большим ростом вычислительных возможностей, памяти и прочего проблема все менее актуальна.
← →
PEAKTOP © (2009-06-10 18:43) [42]> А я не пойму. Транзакция одна в контексте соединения, то
> есть TpFIBDatabase в данном случае. Это шо это получается,
> компонент TpFIBTransaction ставит в очередь все эти транзакции,
> или по надобности одну "резка" завершает, или как-то готовит
> активную для 2-хфазного коммита, или чего там происходит?
Все, что написано ниже, относиться к Firebird c учетом последней версии 2.5. Как там дела у Interbase позже версии 6.0 - не знаю.
Как вообще Джимом Старки все задумывалось: крутиться себе процесс (SuperServer или Embedded) или процессы (ClassicServer или SuperClassicServer) сервера. К нему есть подключения (имеющие свой ID) и транзакции (тоже имеющие свой ID). Отсюда правила:
1) Каждое подключение може иметь N транзакций, где N-инкрементальное число от 0 для последнего restore файла базы данных до предела типа данных LongInt (в Delphi Int64).
2) Каждая транзакция может относится к M подключениям, где M - число типа LongInt (в Delphi Int64).
До конца этот механизм не был реализован в InterBase6.0, но позже путем добавлений feature requests в Firebird этот механизм был реализован на 100%.
То есть в рамках одного подключения ты можешь иметь до фига транзакций, причем у каждой может быть свой уровень изоляции.
В рамках одной транзакции у тебя может быть несколько подключений, например, как в Cross-Database запросах, когда ты внутри тела хранимой процедуры или триггера обращаешься к другой БД ( http://firebirdsql.su/doku.php?id=execute_statement) с параметром WITH COMMON TRANSACTION.
В рамках одной транзакции у тебя может быть вложенная транзакция, которая может выполняться с другим уровнем изоляции данных и блокировки данных. Например, когда ты внутри триггера или хранимой процедуры выполняешь некоторые действия в рамках другой транзакции (http://firebirdsql.su/doku.php?id=autonomous_transaction).
<OFFTOP>
Ув. pasha_golub, можно личный вопрос ? А во сколько ты родился ? Я в 10:00 утра.
День, думаю, уточнять не надо. =))
</OFFTOP>
← →
MsGuns © (2009-06-10 23:13) [43]Первый полноценный скл-сервер, с которым пришлось работать, был ИБ (точнее ФБ 1.0). Быстро "привык" к транзакциям и был весьма раб "рулить" ими, благо сам сервер другого и не преждполагает.
Потом переехал на мсскл. Первое время в голове был "белый шум" с транзакциями ибо "рулить ими как в ИБ просто нельзя. После внятной и прозрачной концепции транзакций ИБ въехать в "мутную" неявную транзакцию мсскл было крайне сложно (может быть возраст сказался). Особенно меня колбасило от вложенности транзакция и неявных транзакций.
Но ничего, привык.
ИМХО, чтобы понять принцип транзакций сервера, нужно прежде всего "въехать" в его "виртуальность", т.е. способ представления данных БД для конкретного клиента (соединения).
Если ИБ есть версионник и хранит версии записей ДЛЯ КАЖДОЙ ТРАНЗАКЦИИ, то мсскл - блокировочник и "пасет" клиента в целом, т.е. коннект.
Возможно, написал коряво, но все-таки истина, ИМХО, где-то здесь ;)
← →
turbouser © (2009-06-10 23:21) [44]
> MsGuns © (10.06.09 23:13) [43]
> Потом переехал на мсскл.
+1 После ib/fb - сущий ужас :(
← →
Игорь Шевченко © (2009-06-10 23:29) [45]MsGuns © (10.06.09 23:13) [43]
turbouser © (10.06.09 23:21) [44]
Что лишний раз подтверждает тезис о трудоемкости и часто бессмысленности написания приложений, абстрагированных от СУБД (дескать, чуть слой доступа к данным подкрутим и все будет работать). Фиги. Не будет или не все или не так, как хотелось. Разумеется, речь не идет о тривиальных приложениях.
← →
MsGuns © (2009-06-10 23:39) [46]Была статья в свое время Акопьянца "Блеск и нищета клиент-серверных технологий" - она в свое время направила меня на путь истинный.
Сегодня она висит у нас в отделе на самом видном месте. Каждого нового сотрудника первым делом заставляю штудировать и читать до полного проникновения.
← →
MsGuns © (2009-06-10 23:40) [47]Кстати, а ведь жив, курилка ;)
http://www.computerra.ru/offline/1999/302/3766/print.html
← →
Игорь Шевченко © (2009-06-10 23:54) [48]MsGuns © (10.06.09 23:40) [47]
Благодарю. А можно ссылки на остальные части ?
← →
MsGuns © (2009-06-11 09:14) [49]Вечером отправлю тебе полную статью по почте, ежели твое мыло актуально
С работы сделать этого не могу ибо тут свои правила :)
← →
TIniFile (2009-06-11 09:26) [50]
> А можно ссылки на остальные части ?
http://akop.ru/personal/1856
← →
vuk © (2009-06-11 11:29) [51]В статье ни одного откровения, из-за которого её стоит вешать на стенку, не обнаружил. А часть про организацию пользовательского интерфейса вообще, по большей части, из бреда состоит, особенно там, где про редактирование данных написано.
← →
PEAKTOP © (2009-06-11 11:43) [52]> Если ИБ есть версионник и хранит версии записей ДЛЯ КАЖДОЙ ТРАНЗАКЦИИ
Это есть не совсем так. Все зависит от уровня изоляции транзакции и того, что эта транзакция делает (только чтение или чтение/запись). Давайте рассмотрим варианты.
Вариант № 1: транзакция isc_tpb_read_committed + isc_tpb_read, то она только читает данные с сервера и на сервере не создаются новые версии записей. При этом:
1) если в параметрах стоит isc_tpb_rec_version, то будут читаться данные от самой последней закоммитченной транзакции.
2) если же будет установлен isc_tpb_no_rec_version, то будет читаться самая последняя версия записей, даже если она принадлежит еще незакоммитченной транзакции.
Вариант № 2 и 3: транзакция isc_tpb_concurrency+isc_tpb_read (еще ее называют SNAPSHOT), то старт ее единственной тоже не приведет к появлению новых версий записей. Зато если после старта этой транзакции стартанет другая (третья, десятая) с любым уровнем изоляции (кроме isc_tpb_read_committed+isc_tpb_read), то версии записей будут плодится как кролики, т.к. серверу нужно будет хранить версию записей на момент старта ЭТОЙ транзакции. А если эта транзакция еще будет и isc_tpb_concurrency+isc_tpb_write (это значение по-умолчанию, когда в любых компонентах доступа не заполнено свойство T<X>Transaction.Params:TStrings), то ко всем вышеперечисленным прелестям добавляются еще и возможные deadlock-и.
Вариант № 4: транзакция isc_tpb_consistency+isc_tpb_write. Лично я бы рекомендовал использовать этот уровень изоляции исключительно для операторов INSERT/UPDATE/DELETE и DDL, т.к. данная транзакция создает новую версию записей "палюбому". А элементарный SELECT * FROM TABLE_NAME (за звездочку в SELECT вообще надо бить молотком по пальцам) в рамках этой транзакции приведет к появлению новой версии записей для всей таблицы. А если в таблице 8-10 млн. записей, то... ну, вы понимаете... =)
Это я все к чему. Firebird версионник, но с настраиваемыми параметрами транзакций. Поэтому он может вести себя по-разному, в зависимости от случая. Из Firebird сделать M$ SQL получиться, для этого нужно использовать во всех наборах данных в свойстве T<X>DataSet.Transaction := T<X>DataBase.InternalTransaction, а свойство T<X>DataBase.InternalTransaction.Params выставить при старте приложения в isc_tpb_concurrency+isc_tpb_write. И мы получаем поведение блокировочника.
← →
Sergey Masloff (2009-06-11 11:49) [53]PEAKTOP © (11.06.09 11:43) [52]
>2) если же будет установлен isc_tpb_no_rec_version, то будет читаться >самая последняя версия записей, даже если она принадлежит еще >незакоммитченной транзакции.
В FB нет (и надеюсь никогда не будет) dirty read
Эта опция читает последнюю ЗАКОММИЧЕНУЮ версию записи. Если после нее есть еще неподтвержденная версия то в зависимости от других параметров или ждем подтверждения/отката или если ожидание не установлено то выдается исключение
← →
PEAKTOP © (2009-06-11 12:02) [54]> В FB нет (и надеюсь никогда не будет) dirty read
Вот, только что у Влада Хорсуна спросил - таки да. Вы абсолютно правы.
← →
Sergey13 © (2009-06-11 12:14) [55]> [51] vuk © (11.06.09 11:29)
Все таки ей (статье) уже 10 лет. Тогда, ИМХО, многие истины еще не были азбучными.
Мне лично, при прочтении, было жалко, что не читал ее тогда.
← →
Игорь Шевченко © (2009-06-11 12:37) [56]
> Мне лично, при прочтении, было жалко, что не читал ее тогда.
Осталось понять, какие статьи надо читать сейчас, чтобы через 10 лет не жалеть:)
Статья неплохая, по меньшей мере она проясняет, что не надо делать, а это уже плюс. Я, например, ряд тезисов понял на собственных ошибках (за какое время:), путь безусловно верных и доходчивый, но довольно долгий :)
← →
Пит (2009-06-11 13:18) [57]PEAKTOP, спасибо больше за пост [52] и Сергею за уточнение.
← →
sniknik © (2009-06-11 13:32) [58]> Все таки ей (статье) уже 10 лет.
это да ... знать бы про нее раньше было бы подспорье в "войне" с TADOTable воспроизводящему десктопную идеологию (первое же "откровение" в статье, да еще с таким примером крушения банка), которую веду с 200x-ного года.
логики на словах у нас не воспринимают, но была бы ссылка на написанное... написанному почему то верят, наверное привычка со времен СССР.
да и остальное полезно, даже сейчас много непонимающих, вот например любой кто задал вопрос в базах и не указал тип субд/используемый к ней доступ, должен прочитать про идентичность.
и про аксесс... прослеживается развитие, тогда это значит было только "фичей" аксесса, ну то как он обновляет данные в связанных структурах (хотя я и не согласен, что не понятно, просто непривычно для IB-шника), а теперь это есть в ADO... похоже тренировались "на кошках". ;)
← →
sniknik © (2009-06-11 13:34) [59]> должен прочитать про идентичность.
вернее про иллюзию идентичности в статье.
← →
Sergey13 © (2009-06-11 13:47) [60]> [56] Игорь Шевченко © (11.06.09 12:37)
> Осталось понять, какие статьи надо читать сейчас, чтобы
> через 10 лет не жалеть:)
Лишь бы не инструкцию по сборке/разборке автомата. 8-)
Сейчас то все таки проще. Интернет есть уже практически везде - рой сколько угодно. А тогда, в конце 90-х, с этим было (особенно в провинции) ой как не просто. Да и книг в магазах было все таки значительно меньше. Поэтому путь проб и ошибок был практически единственным из доступных.
← →
vuk © (2009-06-11 14:02) [61]to Sergey13 © (11.06.09 12:14) [55]:
>Все таки ей (статье) уже 10 лет. Тогда, ИМХО,
>многие истины еще не были азбучными.
Не, если сидеть под файлсерверными базами, то да, наверное не были. Я, насколько себя помню, тогда уже под MS SQL писал. И никаких иллюзий не было. Так что мне что тогда, что сейчас, ничего нового в той статье не открылось бы.
← →
sniknik © (2009-06-11 14:02) [62]> Интернет есть уже практически везде
А помните голодные годы? Интернет по карточкам...
← →
sniknik © (2009-06-11 14:08) [63]> И никаких иллюзий не было.
я тоже у себя подобных иллюзий не помню, но знаю кучу людей которым статья не помешала бы (хотя, большинство из этой кучи ее попросту не поймет :( ).
← →
Игорь Шевченко © (2009-06-11 14:08) [64]vuk © (11.06.09 14:02) [61]
Я в те годы под Оракл и под Interbase писал. Но иллюзии были не сколько у программистов, сколько у потенциальных заказчиков. Может и мне нового не открылось бы, но в статье, на мой взгляд, все очень удачно собрано вместе.
← →
Игорь Шевченко © (2009-06-11 14:09) [65]
> А помните голодные годы? Интернет по карточкам...
а за каждой карточкой 5 км в гору зимой по гололеду
← →
Игорь Шевченко © (2009-06-11 14:15) [66]И вообще - транзакции, фигакции, пустое это все.
Вот как надо делать системы:
http://www.sql.ru/forum/actualthread.aspx?bid=9&tid=669844&pg=1
← →
pasha_golub © (2009-06-11 14:24) [67]
>
> <OFFTOP>
> Ув. pasha_golub, можно личный вопрос ? А во сколько ты родился
> ? Я в 10:00 утра.
> День, думаю, уточнять не надо. =))
> </OFFTOP>
>
Полдень.
← →
Sergey13 © (2009-06-11 14:27) [68]> [61] vuk © (11.06.09 14:02)
> Не, если сидеть под файлсерверными базами, то да, наверное не были.
А я тогда как раз с Клиппера на Делфийского Оракула переползал. С трудом.
← →
pasha_golub © (2009-06-11 14:33) [69]Для мозгов переползание с файлсерверного чуда трудно дается. По себе помню. Буря прямо внутре.
← →
sniknik © (2009-06-11 14:55) [70]> А я тогда как раз с Клиппера на Делфийского Оракула переползал. С трудом.
> Для мозгов переползание с файлсерверного чуда трудно дается. По себе помню. Буря прямо внутре.
да бросьте, нормально с фохпро на первасвиль "пересел".
сначала непривычно было, и только то, что нельзя напрямую таблицу отрыть/индекс ей назначить (начал естественно с этого), но как только "дошло", что работая с сервером работаешь не с самими таблицами, а по сути с другим приложением "дошло" и то, что все это совсем совсем другое и надо не "пересаживаться", а изучать новое. и в общем то все, "буря" кончилась, не начинаясь, буквально при первом прямом знакомстве (читал про сервер первасвиля, пока он у меня не появился, несколько дольше, но "осознания" этого простого факта не было, пока сам не "пощупал").
кстати потом это понимание, перенес и на компоненты ADO которые борланд делал именно для переходя с BDE (десктоп в основном) программ, ратуя за то, чтобы их убрать, а к ADO относится как к новому, и изучать именно то, что он есть, его родные компоненты, а не "привычные переходники" (старые привычки = новые глюки в новом).
← →
vuk © (2009-06-11 16:28) [71]to Игорь Шевченко © (11.06.09 14:08) [64] :
>Но иллюзии были не сколько у программистов, сколько
>у потенциальных заказчиков.
Потенциальный заказчик, начитавшись такого, скорее всего сделает вывод, что серверные БД - дерьмо и развод лохов на баппки. :)
← →
MsGuns © (2009-06-11 16:37) [72]Во как задела статья :)
Почему на стене объясню.
Практически 100% приходящих выпускников и практикантов (дипломников) нашего политеха имеют типичное файл-серверное мышление, старательно втоптанное в их чистые светлые головы преподавателями - "мастерами". Бороться с которым (мышлением) в одиночку ох как тяжко. А тут тнкул носом в стену, дал срок неделю-другую для воплощения прочитанного - и проверяй результат.
Как показывает практика - весьма эффективная метода.
Мне кажется, что подобная ситуация далеко не редкость. Более того, встречается чуть ли не повсеместно.
← →
Игорь Шевченко © (2009-06-11 16:44) [73]vuk © (11.06.09 16:28) [71]
Потенциальный заказчик таких статей не читает. Потенциальный заказчик, хочет, чтобы его задачи решались в приемлемое время. А исполнители заказчика хотят, чтобы был приемлемый отклик. Когда им объясняют, что приемлемый отклик будет за счет отсутствия привычных удобств (в ряде случаев), у них начинается внутренний конфликт. Иногда заказчик игнорирует мнений своих исполнителей, иногда нет :)
← →
PEAKTOP © (2009-06-11 16:51) [74]> Практически 100% приходящих выпускников и практикантов (дипломников)
> нашего политеха имеют типичное файл-серверное мышление,
> старательно втоптанное в их чистые светлые головы преподавателями
> - "мастерами"
+ 1 000 000
-- Как я Вас понимаю...
-- Нет, Вы не понимаете...
-- Я отлично Вас понимаю...
.......
(с) Реклама по ящику
Обратное "размагничивание" мозгов выпускников - это отдельная тема. И очень даже не юмора. Особенно когда их старательно "намагничивали" в течение пяти лет придурки, оставшиеся на уровне развития технологий середины 90-х годов. У нас в провинции это особенно актуально.
← →
PEAKTOP © (2009-06-11 16:57) [75]> pasha_golub © (11.06.09 14:24) [67]
>
> Полдень.
>
Значит, на пару часов младше :)))))
← →
vuk © (2009-06-11 19:20) [76]to PEAKTOP © (11.06.09 16:51) [74]
>Особенно когда их старательно "намагничивали"
>в течение пяти лет придурки, оставшиеся на уровне
>развития технологий середины 90-х годов.
А, собственно, кто мешал этим выпускникам самим поинтересоваться, что же там нынче на дворе происходит? Их в яндексе поголовно забанили?
← →
PEAKTOP © (2009-06-11 19:58) [77]> кто мешал этим выпускникам самим поинтересоваться
Да кто его знает...
Но, как говорил первый президент Украины Л.М.Кравчук "Имеем то, что имеем..."
В условиях 200 000 города с единственным ВУЗом, готовящим по специальности, выбирать особенно не приходится.
Приходится "перезатачивать" !
=))))
← →
MsGuns © (2009-06-11 20:55) [78]>vuk © (11.06.09 19:20) [76]
>А, собственно, кто мешал этим выпускникам самим поинтересоваться, что >же там нынче на дворе происходит? Их в яндексе поголовно забанили?
Я, конечно, извиняюсь, но..
Такое впечатление, что Вы учились в Массачусетском технологическом ;)
← →
Игорь Шевченко © (2009-06-11 20:58) [79]Я вот учился вообще не по программированию, и как ни странно, Яндекса в то время ну нифига не было. И за каждой книжкой в библиотеку по 5 км в гору зимой по гололеду, да еще очередь отстаивать. И неплохо, надо признать, при всем при этом выучился программировать.
← →
MsGuns © (2009-06-11 21:04) [80]Так веь на одного Шевченко триста тридцать три Ковалей и Петренок ;)))
← →
pasha_golub © (2009-06-11 21:23) [81]
> PEAKTOP © (11.06.09 16:57) [75]
>
> Значит, на пару часов младше :)))))
Значит, буду на пару часов трезвее :))))
← →
pasha_golub © (2009-06-11 21:25) [82]А что мешает вот в остальных серверах прикрутить такую мульку типа :
SWITCH TRANSACTION CONTEXT TO <ident>;
Ведь 2-хфазный коммит почти у всех есть, а эта фишка и того проще реализуется (я подозреваю). Или раз нету ни у кого кроме Файрберда, следовательно не настолько велика фишка?
← →
vuk © (2009-06-11 21:46) [83]to MsGuns © (11.06.09 20:55) [78]
>Такое впечатление, что Вы учились в Массачусетском технологическом ;)
Да, я учился в МТИ. Но не в том. :)
Вообще, я честно говоря, не понимаю, что мешает во время обучения в ВУЗе что-то еще самому параллельно изучать, если видно, что не хватает каких-то знаний. Лень? Ну так это чьи проблемы-то? :) Нам, вот, тоже фокспро преподавали, а не серверные БД. И что с того?
← →
MsGuns © (2009-06-11 22:24) [84]>vuk © (11.06.09 21:46) [83]
>Вообще, я честно говоря, не понимаю, что мешает во время обучения в >ВУЗе что-то еще самому параллельно изучать, если видно, что не хватает >каких-то знаний.
Да очмного чего.
1) Девушки
2) Футболы/волейболы/баскетболы/теннисы/велосипеды и тд
3) Хорошие компании
4) Музыка
5) Кино, театр, фестивали..
6) Куча всяких абавных хреновин, начиная от праздников и заканчивая розыгрышами и приколами.
Хотя, еслм Вы не жили в общаге, то, ИМХО, половина Вам непонятна просто
Зубрить науку в бурсе - дело последнее. Надо наслаждаться юностью, здоровьем и свободой, потом или того, или другого, или третьего не будет. Человек, осмысленно готовящий себя в ВУЗе к ОПРЕДЕЛЕННОЙ работе - явление чрезвычайно редкое, по крайней мере в мое время, и ничего, кроме сочувствия, у окружающих не вызывает.
← →
Kerk © (2009-06-11 22:27) [85]
> MsGuns © (11.06.09 22:24) [84]
> 6) Куча всяких абавных хреновин
Вот сюда как раз входит все что угодно, начиная от ассемблера, заканчивая базами данных. У всех разные интересы :)
← →
Игорь Шевченко © (2009-06-11 22:33) [86]
> Надо наслаждаться юностью, здоровьем и свободой, потом или
> того, или другого, или третьего не будет
Эт точно, потом лабу/курсач/диплом за деньги заказать слегка труднее будет
← →
vuk © (2009-06-11 23:02) [87]to MsGuns © (11.06.09 22:24) [84]:
>Да очмного чего.
Э... Нафига тогда в ВУЗ ходить? За липовыми корочками?
← →
MsGuns © (2009-06-11 23:38) [88]>vuk © (11.06.09 23:02) [87]
>Э... Нафига тогда в ВУЗ ходить? За липовыми корочками?
Институт учит двум вещам главным образом: умению учиться и умению постоять за себя.
При достаточно развитых этих навыках молодой специалист не пропадет нигде.
Я вот учился в авиаинституте, но ни дня не работал в авиапромышленности. Спрашивается, зачем было зубрить самолетостроение, термех, основы электротехники, машиностроительное черчение и тучу всяких других наук, которыми меня кормили 5,5 лет ?
А другой 4 года изучал языки программирования и базы данных, а работать суждено было в торговой сети экономистом или банке охранником.
Хотя, конечно, у каждого свои представления об учебе в ВУЗе. Если у Вас то, что Вы там изучали, явилось базой для дальнейшей профессии и карьеры, то слава Богу. Но таких все же подавляющее меньшинство. Мы не Америка и не Европа, мы - Азия.
← →
Игорь Шевченко © (2009-06-11 23:45) [89]MsGuns © (11.06.09 23:38) [88]
География тоже не нужна покуда извозчик есть
← →
MsGuns © (2009-06-11 23:49) [90]>Игорь Шевченко © (11.06.09 23:45) [89]
>География тоже не нужна покуда извозчик есть
Ага, вилка тоже не нужна - можно хавать руками.
Давай не будем ерничать, а ?
← →
Petr V. Abramov © (2009-06-11 23:59) [91]вилка vs палочки, вот в чем вопрос, а не вилкой жрать или харей в рыбу
:)
← →
Игорь Шевченко © (2009-06-12 00:54) [92]
> Давай не будем ерничать, а ?
> Спрашивается, зачем было зубрить самолетостроение, термех,
> основы электротехники, машиностроительное черчение и тучу
> всяких других наук, которыми меня кормили 5,5 лет ?
Географией наверное тоже в школе пару лет кормили перед этим. А нафига ? И образ Базарова по жизни не пригодился.
← →
Petr V. Abramov © (2009-06-12 01:17) [93]
> И образ Базарова по жизни не пригодился.
атвечать нэ учит, да?
← →
MsGuns © (2009-06-12 01:26) [94]>Игорь Шевченко © (12.06.09 00:54) [92]
>Географией наверное тоже в школе пару лет кормили перед этим. А >нафига ? И образ Базарова по жизни не пригодился.
Т.е. ты хочешь сказать, что без знания технологии самолетостроения или без основ функанализа человек столь же безграмотен, как и тот, что "читал" Бетховена или считает, что Америка граничит с Украиной ?
← →
Игорь Шевченко © (2009-06-12 01:36) [95]MsGuns © (12.06.09 01:26) [94]
Я хочу сказать, что если ты 5,5 лет учился "стоять за себя", то можно было выбрать область, ну скажем так, без самолетостроения.
ЗЫ: читают обычно Ван-гога.
← →
Германн © (2009-06-12 02:02) [96]
> vuk © (11.06.09 19:20) [76]
Полностью согласен!
Я даже не о том, что все здешние мастера (может кроме ЮЗ) не получали "нормального" образования по программированию.
Я о том, что если хочешь чем-то овладеть, то нужно стремиться и стараться самому.
← →
Холивар (2009-06-12 02:46) [97]
> pasha_golub © (10.06.09 09:22)
>
> Вот тут общались с адептом Интербейз (файрберд) + FIBPlus
> и он мне тыкал: "мол, цыгане вы неразумные. У нас вот TpFIBTransaction.
> поназначал каждому query по транзакции и вперед в многопоточность.
> каждая qeury когда захотела и дергается к базе, а TpFIBTransaction
> рулит"
Он не адепт, он адиот!
Нельзя из нескольких потоков одновременно что-то делать через одно DBConnection. Это сами разработчики Firebird говорят(про IB не знаю). Несколько транзакций в одном подключении нужны только тогда, когда тебе в одном потоке!!! нужно работать одновременно с двумя и более Query вот там эта фишка рулит, так как чуть-чуть снижает нагрузку на сервер.
← →
MsGuns © (2009-06-12 08:03) [98]>Холивар (12.06.09 02:46) [97]
Сам понял что сказал ?
← →
Холивар (2009-06-12 15:21) [99]
> MsGuns © (12.06.09 08:03) [98]
>
> >Холивар (12.06.09 02:46) [97]
>
> Сам понял что сказал ?
Угу. Например один Query в snapshot транзакции - читающий, другой в пишущей ReadCommited. В общем такое более подходит для работы с базой из основного VCL потока и кучи разных форм. Многопоточностью там и не пахнет.
Если много потоков то должно быть или много DBConnection или синхронизация к одному DBConnection через CS.
← →
PEAKTOP © (2009-06-12 17:25) [100]> Нельзя из нескольких потоков одновременно что-то делать через одно DBConnection
Бред.
> Если много потоков то должно быть или много DBConnection или синхронизация к одному DBConnection через CS.
Слушай, а вот это: http://sql.ru/forum/actualthread.aspx?tid=671770 не ты ли затеял ?
Читай ответ Dimitry Sibiryakov http://sql.ru/forum/actualthread.aspx?tid=671770#7293820
← →
MsGuns © (2009-06-12 17:39) [101]>Холивар (12.06.09 15:21) [99]
>Угу. Например один Query в snapshot транзакции - читающий, другой в пишущей >ReadCommited. В общем такое более подходит для работы с базой из основного VCL потока и >кучи разных форм. Многопоточностью там и не пахнет.
Вы путаете потоки и транзакции. Что имеется в виду под "работой с базой из основного VCL-потока" ? И каким образом можно организовать "многопоточность" при извлечении данных и их правкой (апдейтами) - не успели прочитать, как уже редактируем ?
>Если много потоков то должно быть или много DBConnection или синхронизация к одному >DBConnection через CS.
С какой радости ?
← →
Игорь Шевченко © (2009-06-12 17:41) [102]
> С какой радости ?
не знаю, как насчет IB, но в оракле, например, крайне желательно для каждого потока открывать свое соединение.
← →
MsGuns © (2009-06-12 17:52) [103]Если потоки являются взаимонезависимы, т.е. получают каждый свои данные и только сам же их обрабатывает, то коннект для каждого потока создавать необязательно. А вот если зависимость имеется, т.е. один поток получает данные, а второй их обрабатывает и отсылает не сервер изменения, таки да. И в этом случае надо строить неслабую систему синхронизации. (к вопросу о все решающем TClientDatasSet, если я правильно расшифровал аббревиатуру Холиваара)
Но вот второй случай - это вообще-то специфика систем РМВ. В обычных же "базовых" приложениях одна транзакция читает, а другая пишет. Обе в одном соединении. Только причем здесь многопоточность ?
← →
MsGuns © (2009-06-12 17:57) [104]Кстати, при создании многопоточной технологии работы с БД приходится очень много чесать репу ибо при "обычном" подходе выясняется, что много эффективнее отсылать запросы серверу и обрабатывыать результаты последовательно, нежели каждый пихать в поток. При этом нет выигрыша по скорости (даже проигрыш) и винда периодически "подвешивается".
Вот сейчас как раз пишу такую фиговину - разузловка нескольких составов изделий одновременно с отображением хода каждого процесса типа On-line.
Куча мелких и не очень проблем, хотя потоки взаимонезависимы.
← →
Игорь Шевченко © (2009-06-12 19:20) [105]
> Если потоки являются взаимонезависимы, т.е. получают каждый
> свои данные и только сам же их обрабатывает, то коннект
> для каждого потока создавать необязательно
такая концепция приводит в ряде случаев к трудноуловимым ошибкам.
> Кстати, при создании многопоточной технологии работы с БД
> приходится очень много чесать репу ибо при "обычном" подходе
> выясняется, что много эффективнее отсылать запросы серверу
> и обрабатывыать результаты последовательно, нежели каждый
> пихать в поток. При этом нет выигрыша по скорости (даже
> проигрыш) и винда периодически "подвешивается".
Все зависит от задачи и от используемого сервера. А что до "винда подвешивается", так то зависит от танцора
← →
Холивар (2009-06-12 19:30) [106]
> PEAKTOP © (12.06.09 17:25) [100]
>
> > Нельзя из нескольких потоков одновременно что-то делать
> через одно DBConnection
>
> Бред.
Результатом такого подхода - доступ к базе из нескольких потоков - потом становятся долгие месяцы отлова бага в каком-либо серьезном проекте. Так как юнит-тесты для многопоточного тестирования писать не очень просто и результаты не всегда однозначны.
До сих пор многопоточное программирование удел Senoir Developers.
← →
turbouser © (2009-06-12 19:32) [107]
> Холивар (12.06.09 19:30) [106]
> До сих пор многопоточное программирование удел Senoir Developers.
Это кто такие?
← →
Холивар (2009-06-12 20:26) [108]
> turbouser © (12.06.09 19:32) [107]
>
>
> > Холивар (12.06.09 19:30) [106]
>
>
> > До сих пор многопоточное программирование удел Senoir
> Developers.
>
> Это кто такие?
Senior Developers
← →
turbouser © (2009-06-12 20:41) [109]
> Холивар (12.06.09 20:26) [108]
Да я и так догадался. Интересно просто, как это определяется - сеньер девелопер или не сеньер?
И почему у них такой удел?
← →
PEAKTOP © (2009-06-12 21:00) [110]> Результатом такого подхода - доступ к базе из нескольких
> потоков - потом становятся долгие месяцы отлова бага в каком-
> либо серьезном проекте
Молодой человек, я шо-то совсем Вас не пойму.
Вы таки на шо жалуетесь: на проблемы при написании многопоточных приложений для Firebird, работающих через один хендл подключения, или на неумение программировать ?
Первое - бред. Это я Вам как Firebird Foundation DocWriter заявляю. Через один хендл подключения (компонент T<..>DataBase) нормально работают мультитредовые приложения. Даже в поделке Джефа Оверкеша под названием IBX.
Второе - не проблема, научитесь.
> Интересно просто, как это определяется - сеньер девелопер или не сеньер?
Наверное, наличием сертификата ?
Только вопрос, кто его выдает-то. Я вот ни разу не синьор, и даже не джуниор. Но писать нормально мне это не мешает.
А пару сеньоров даже в моей глухой провинции доводилось встречать. За то, как они реализовывали некоторые тривиальные веши - надо бить молотком по пальцам. Шоб говнокода в мире не стало еще больше.
← →
turbouser © (2009-06-12 21:06) [111]
> PEAKTOP © (12.06.09 21:00) [110]
> За то, как они реализовывали некоторые тривиальные веши
> - надо бить молотком
Так я потому и спрашиваю... Весь кайф обломал :)
← →
Холивар (2009-06-12 22:14) [112]
> PEAKTOP © (12.06.09 21:00) [110]
>
> Первое - бред. Это я Вам как Firebird Foundation DocWriter
> заявляю. Через один хендл подключения (компонент T<..>DataBase)
> нормально работают мультитредовые приложения.
Только и в литературе по FireBird и в документации очень не рекомендуется так делать. Простое правило 1 коннект - одновременно один поток приведёт к серьезному сокращению времени на будущий багфиксинг. А пул коннектов Java-like написать совсем не проблема.
← →
Холивар (2009-06-12 22:16) [113]
> turbouser © (12.06.09 20:41) [109]
>
>
> > Холивар (12.06.09 20:26) [108]
>
> Да я и так догадался. Интересно просто, как это определяется
> - сеньер девелопер или не сеньер?
> И почему у них такой удел?
Сеньёр - тот кто пишет ПО не так чтобы код круто выглядел, а чтобы работало, по-возможности, всегда и везде без особых проблем.
← →
turbouser © (2009-06-12 22:42) [114]
> Холивар (12.06.09 22:16) [113]
> Сеньёр - тот кто пишет ПО не так чтобы код круто выглядел,
> а чтобы работало, по-возможности, всегда и везде без особых
> проблем.
Нет.. не быть мне сеньером...
← →
PEAKTOP © (2009-06-13 10:54) [115]> Только и в литературе по FireBird и в документации очень не рекомендуется так делать
Вы внимательно этот абзац прочитайте. Полностью прочитайте, особенно тот момент, где описывается в каких имеено случаях.
<OFFTOP>
У нас в Украине уголовный кодекс наносить гражданам тяжкие телесные повреждения тоже не рекомендует делать. А в случаях необходимой самообороны при нападении - разрешает. А из жизненного опыт Вам скажу, что это не только можно делать, но и нужно делать.
=)
</OFFTOP>
← →
Anatoly Podgoretsky © (2009-06-13 11:02) [116]> PEAKTOP (13.06.2009 10:54:55) [115]
Ты угрожаешь?
← →
PEAKTOP © (2009-06-13 11:26) [117]> Anatoly Podgoretsky © (13.06.09 11:02) [116]
>
> Ты угрожаешь?
Да боже упаси. Я аналогию просто провел =)
← →
MsGuns © (2009-06-13 13:14) [118]>Игорь Шевченко © (12.06.09 19:20) [105]
>такая концепция приводит в ряде случаев к трудноуловимым ошибкам.
Там написано "Необязательно". Не углядел ?
>Все зависит от задачи и от используемого сервера. А что до "винда >подвешивается", так то зависит от танцора
Свои тараканы, конечно, всегда имеются в виду. Но !.
ADO в "компании" с мсслл тоже не идеальны. Например, при работе в асинхронном режиме. Это нужно, чтобы иметь возможность по требованию клиента прекратить выполнение сервером некоторой работы (в данном случае - разузлования, котрое может продолжаться минуты и даже десятки минут).
Указываешь асинхрон коннекту - ничего не виснет на экране, но и сервер не останавливается пока не завершит работу. Даешь асинхрон команде - сервер рубится почти мгновенно, но виснет прога. Где-то есть, наверное, решение, но пока вот не нашел..
← →
MsGuns © (2009-06-13 13:17) [119]Да, не сказал главного. При работе в одном потоке нет никаких зависаний. Они начинаются при запуске нескольких потоком, причем чем больше потоков, тем дольше зависания. На каждый поток - свой коннешн и свой комманд
← →
sniknik © (2009-06-13 15:51) [120]> Указываешь асинхрон коннекту - ничего не виснет на экране
асинхрон коннекта это именно для коннекта... в локальной сети практически без разницы что использовать, в ней не бывает подключений по полторы минуты (пример).
> Даешь асинхрон команде - сервер рубится почти мгновенно, но виснет прога.
ждет ответа, а ответа на будет пока сервер не выполнит какую то неделимую часть запроса.
возможно глюк компонента.
> Где-то есть, наверное, решение, но пока вот не нашел..
асинхрон команде, а для ее остановки "глушить" коннект (active:= false).
должно получиться... и если получится смотри действия которые выполняются, для команды при закрытии коннекта в генофонде.
но вообще, при асинхронной работе с ADO не нужны свои потоки, т.е. асинхронность это и есть выполнение команд в доп. потоках, только созданных не вами, а самим ADO. если делаются свои, то их работа и внутренних ADO должна согласовываться. (что несколько проблематично, т.к. такой схемы не предусмотрено, а код объектов ADO закрыт)
> На каждый поток - свой коннешн и свой комманд
можно и один коннект в общем и "свой комманд" в каждом потоке (без асинхронности!), но тогда общий коннект будет ставить команды в общую очередь. т.е. будет не совсем то, что хочется, когда делаешь потоки, так?
в общем у ADO есть своя идеалогия (как и у транзакций в сабже и всего другого), и ее нужно соблюдать, или будут глюки.
← →
Холивар (2009-06-13 18:28) [121]
> PEAKTOP © (13.06.09 10:54) [115]
>
> > Только и в литературе по FireBird и в документации очень
> не рекомендуется так делать
>
> Вы внимательно этот абзац прочитайте. Полностью прочитайте,
> особенно тот момент, где описывается в каких имеено случаях.
>
>
> <OFFTOP>
> У нас в Украине уголовный кодекс наносить гражданам тяжкие
> телесные повреждения тоже не рекомендует делать. А в случаях
> необходимой самообороны при нападении - разрешает. А из
> жизненного опыт Вам скажу, что это не только можно делать,
> но и нужно делать.
> =)
> </OFFTOP>
Я почему-то предпочитаю не доводить ситуацию до "нанесения тяжких телесных повреждений". Это гораздо проще, чем доказывать потом что именно ты прав.
Поэтому правило 1 поток - 1 коннект хорошо для любых ситуаций.
← →
MsGuns © (2009-06-13 19:44) [122]>sniknik © (13.06.09 15:51) [120]
>но вообще, при асинхронной работе с ADO не нужны свои потоки, т.е. >асинхронность это и есть выполнение команд в доп. потоках, только >созданных не вами, а самим ADO. если делаются свои, то их работа и >внутренних ADO должна согласовываться. (что несколько проблематично, >т.к. такой схемы не предусмотрено, а код объектов ADO закрыт)
В потоке не только посылается запрос и принимаются результаты - там еще выполняется обработка этих результатов, "упаковка" их в блоки данных. Главный лишь отображает результаты, периодически опрашивая потоки либо реагируя на их синхровызовы (в зависимости от указанного режима).
"Свой" коннект на поток обязателен, т.к. необходимо иметь возможность программно прерывать поток, корректно закрывая соединение. Если соединение одно для всех потоков, то при "прерванном" потоке может случиться блокировка таблиц на сервере.
>в общем у ADO есть своя идеалогия (как и у транзакций в сабже и всего >другого), и ее нужно соблюдать, или будут глюки.
Глюки можно преодолевать, но много надо морщиться. О чем я и писал, собственно
Страницы: 1 2 3 4 вся ветка
Форум: "Прочее";
Текущий архив: 2009.08.16;
Скачать: [xml.tar.bz2];
Память: 0.86 MB
Время: 0.009 c