Здравствуйте, Пацак, Вы писали:
П>Что делать, такая вот уж плохая система, бывает иногда, что требуются и такие.
Нет, не требуются. Хотя бывает, что другой написать не получается — это да, это факт.
П> Не вижу причин, почему бы других заказчиков не должны удовлетворить обсуждаемые здесь параллельные транзакции, которые при правильном использовании гораздо более безопасны и надежны, чем описаная модульная мешанина.
Тем что они опасны и не надежны.
П> Кто-то утверждал, что использование данных транзакции А в транзакции Б — это исключительно firebird-заморочки,
Ну у вас ребята и каша. Вы меня даже не читаете.
Я утверждал, что использование "параллельных" транзакций из одного потока — любят использовать почему-то только любители FB.
Здравствуйте, pnv82, Вы писали:
P>Ну, а кто же еще виноват?
Ты конечно, так как не слушаешь аргументов, которые тебя не устраивают.
P> Ты говоришь про какую-то систему, на Оракле, с неизвестной архитектурой и внутренностями, СЕРИАЛИЗОВАННЫМИ, вследствии архитектуры Оракла, транзакциями
Ты даже не читаешь того что тебе пишут, я уже не говорю о том, чтобы попытаться понять. Это был пример про длинные транзакции, а не сериализованные — длинные, понимаешь?
P> Даже теоретически нигде изолированность там не нарушается,
Точно, не читаешь, так я и думал.
P> как и где, в моем примере, нарушается изолированность транзакций.
Если в твоем примере изолированность транзакций не нарушается, то нет никакой причины, по которой их нельзя было бы сериализовать. Это задачка для первокласника. Таким образом, возвращаясь к началу спора, необходимости в параллельных транзакциях из одного потока — нет.
Более того, возвращаясь к твоей задачке, у тебя обращение к БД идет в UI-ном потоке?
P>??? А никто и не говорил, что они там необходимы, или обязательны — они возможны и удобны.
С тем что они возможны — никто не спорит, мой поинт в том, что их использование из одного потока — вредно.
P>Так вот, грубо говоря, там же я использовал одно подключение, но с несколькими транзакциями
Ну вот я и пытаюсь понять зачем ты это делал. Так как в нормальных сценариях это сложнее, а тот ненормаьный который вы пытаетесь мне навязвть вообще не имеет права на жизнь.
P>Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом.
Ну вот надо прислушиваться к кругозору и излагаемому опыту, а не упираться в привычный сценарий.
P> ибо я не вижу, как иначе прекратить передергивания и неаргументированные заявления.
Поздно. Я знаю другой действенный способ — перенести тему в священные войны.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Tonal-, Вы писали:
T>>Мне всегда казалось, что ACID — это гарантии именно сервера относительно данных. IB>Ты ошибался.
Вполне может быть.
В таком случае, привиди ссылки на стандарты и документацию, которые подтверждают твоё утверждение.
Устроют ссылки на стандарт SQL 2003 или на онлайн документацию по любому серверу. С точностью до абзаца.
Идеально было бы ещё запрстить сюда цтатау, однозначно подтверждающую твою правоту.
Согласись, что если сервер претендует на предоставление каких-то гарантий, должно быть явно описано при каких условиях эти гарантии эти гарантии не действительны.
Иначе это ен может называться гарантиями.
T>>Если рассмотреть твой ответ, то ни один снервер просто не в состоянии предоставить эти самые гарантии, что бы не написал разработчик. IB>Даже не рассматривая моего ответа должно быть очевидно, что при должной ловкости рук можно обойти любую систему. Но это вовсе не значит, что это нужно делать.
Причём тут ловкость рук?
По твоим словам выходит, что любая программа, которая хоть как-то использует данные вне транзакции нарушает эти самые мифические гарантии.
Здравствуйте, IB, Вы писали:
П>>Что делать, такая вот уж плохая система, бывает иногда, что требуются и такие. IB>Нет, не требуются.
Бороться со святой верой не намерен — это личное дело каждого верующего.
IB>Ну у вас ребята и каша. Вы меня даже не читаете. IB>Я утверждал, что использование "параллельных" транзакций из одного потока — любят использовать почему-то только любители FB.
...тем более когда оппонент постоянно переводит тему.
T>>Ведь для любого сервера можно написать клиента, который их (*) нарушит.
IB>Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.
(*) ACID
IB>>Ооох.. Я где-то говорил, что в этом виновата только одновременная транзакция?!! Ясен байт, что ничто не мешает так сделать на любом другом сервере. Я лишь утверждал что так делать нельзя, а уж какой сервер и каким способом нагибают, из одного подключения или нет — не важно.
П>> Возможность есть, а пользоваться ей или нет — это уж каждый для себя решает сам, в каждом конкретном случае.
IB>Эта возможность есть везде, но почему-то на других серверах это никому в голов не приходит.
Теперь вот потоки еще зачем-то приплел, еще немного — и до гетерогенных запросов докатимся... В общем нафиг такой спор, хочешь считать всех программистов firebird тупорылыми придурками, считаешь устройство MSSQLя (да благославит его аллах и приветствует) единственно верным — это твое личное дело, а я пас.
Здравствуйте, Пацак, Вы писали:
П> Бороться со святой верой не намерен — это личное дело каждого верующего.
Ок, верьте..
П>...тем более когда оппонент постоянно переводит тему.
Я не меняю, это вы за темой не следите.
Ты в чем-то не согласен с процитированным текстом?
П> Теперь вот потоки еще зачем-то приплел,
Я приплел?! Ребята, у вас какая-то фатальная проблема с отслеживанием хода дискуссии...
П> В общем нафиг такой спор, хочешь считать всех программистов firebird тупорылыми придурками,
Ну, к тому чтобы сформировалось такое мнение, в этом топике было приложено очень много усилий..
Здравствуйте, Tonal-, Вы писали:
T>Идеально было бы ещё запрстить сюда цтатау, однозначно подтверждающую твою правоту.
Тебе не кажется, что было бы странно, если бы в стандарте было упомянуто, что "Tonal- ошибается в своей трактовке ACID".
T>По твоим словам выходит, что любая программа, которая хоть как-то использует данные вне транзакции нарушает эти самые мифические гарантии.
Во-первых, я ни слова не говорил про гарантии вообще и гарантии сервера в частности, а во-вторых, из моих слов совсем не следует что любое использование данных нарушает ACID.
Здравствуйте, IB, Вы писали:
P>> Ты говоришь про какую-то систему, на Оракле, с неизвестной архитектурой и внутренностями, СЕРИАЛИЗОВАННЫМИ, вследствии архитектуры Оракла, транзакциями IB>Ты даже не читаешь того что тебе пишут, я уже не говорю о том, чтобы попытаться понять. Это был пример про длинные транзакции, а не сериализованные — длинные, понимаешь?
Ок, и что же делалось в тех длинных транзакциях в Оракле?
Второе — сколько коннектов открывалось с одного клиента, если это была двухзвенка?
P>> Даже теоретически нигде изолированность там не нарушается,
P>> как и где, в моем примере, нарушается изолированность транзакций. IB>Если в твоем примере изолированность транзакций не нарушается, то нет никакой причины, по которой их нельзя было бы сериализовать. Это задачка для первокласника. Таким образом, возвращаясь к началу спора, необходимости в параллельных транзакциях из одного потока — нет. IB>Более того, возвращаясь к твоей задачке, у тебя обращение к БД идет в UI-ном потоке?
P>>??? А никто и не говорил, что они там необходимы, или обязательны — они возможны и удобны. IB>С тем что они возможны — никто не спорит, мой поинт в том, что их использование из одного потока — вредно.
P>>Так вот, грубо говоря, там же я использовал одно подключение, но с несколькими транзакциями IB>Ну вот я и пытаюсь понять зачем ты это делал. Так как в нормальных сценариях это сложнее, а тот ненормаьный который вы пытаетесь мне навязвть вообще не имеет права на жизнь.
P>>Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом. IB>Ну вот надо прислушиваться к кругозору и излагаемому опыту, а не упираться в привычный сценарий.
P>> ибо я не вижу, как иначе прекратить передергивания и неаргументированные заявления. IB>Поздно. Я знаю другой действенный способ — перенести тему в священные войны.
Какие-то нелепые и бредовые обвинения скипаю — если тебе кажет
Хм. Не понял — мессага не ушла или кто-то снова балуется? Хотя может и браузер глючит, но прецеденты были. Повторюсь тогда.
A>> Я процитировал на всякий случай. IB>О чем речь-то?
Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?
A>>Сами ратуете за то чтобы расширяли кругозор, а простую истину понять не можете. IB>Проблема похоже в том, что я простую мысль объяснить не могу..
Ну не совсем простую, но см. ниже. Я думаю что причина там. И любые споры с Вами бесполезны именно по этой причине. Все что я видел в посте, это голословные утверждения "Должно быть так и только так". Очень жаль.
A>> А Вам скольких способов хватает? IB>Достаточно одного.
Всем доподлинно известно что любую задачу можно решить минимум 2-3 способами. Причем методики решения могут кардинально отличаться, и все будут давать правильные результаты. Именно поэтому я не могу никогда сказать, что я нашел все доступные способы решения задачи. Ну приучили меня к этому, и это мировоззрение я считаю верным, т.к. человек не бог, и я не бог. Я не могу увидеть все решения задачи, хотя вижу их по 2-3 практически всегда, а частенько и больше. Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.
P.S. И все-таки, VS? Вы на вопрос так и не ответили. Честно скажу — еще одну священную войну я заводить не собираюсь. Клянусь. Мне глубоко по барабану кто на чем пишет. Главное чтобы правильно.
Здравствуйте, IB, Вы писали:
P>>Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом. IB>Ну вот надо прислушиваться к кругозору и излагаемому опыту, а не упираться в привычный сценарий.
Это должно быть взаимно.
С одной стороны.
С другой — FB-шники, как ты их тут окрестил, по определению не могут упираться в привычный сценарий — потому что на этом сервере этих сценариев — "до-жопы". Хочешь так. Хочешь эдак. Хочешь вообще по-другому. Кто-то взял на вооружение только одно. А кто-то, до текущего момента, эти вопросы (а как?) — вообще не беспокоили — что уместно, то и юзает. Об этом было достаточно недвусмысленно сказано. Очень много раз. Без навязывания — ты накуй никому из них нужен.
Лично я понимаю и тех и других. И третьих. И тех кто работает в автокоммите — тоже, лентяев и самоубийц, понимаю. Полагаю, за все это время что пытаюсь постичь дао управления сервером базы данных, перепробовал или трогал все. Или обеспечивал поддержку на уровне компонент доступа.
Один коннект — одна транзакция. В разных потоках. В DCOM сервере.
Один коннект — несколько транзакций в разных потоках. В фоновых потоках пишется лог и осуществляется перидическое сканирование таблицы движения документов. Запросы во всех потоках кратковременные, поэтому очереди возле трубы с подключением не возникает.
Один коннект — несколько одновременно живущих транзакций в одном потоке. Когда писал "движок" для управления обновляемым множеством в провайдере. Как один из вариантов — хочешь обновляй в той же транзакции что и выборка, хочешь в другой. Наверное, у каждого варианта есть и преимущества и недостатки. Мне по-барабану — оттестировал и забыл. Сам я обновляемые множества даже косвенно не использую. Но заработал достаточно много денег, продавая провайдер пользователям MSSQL, которые используют эти множества Думаю, они вряд ли что там крутят в настройках — поэтому и грузят и обновляют в одной транзакции. А две транзакции — для тех кто точно знает чего он хочет.
Кроме обновляемых множеств, возможно в дебрях скриптовой бизнес-логики нашего программного комплекса тоже есть запуск-коммит независимой транзакции, время жизни которой пересекается с другой транзакцией. Я бы ошалел если бы увидел там явное открытие отдельного подключения. Ошалел, но не умер бы.
Если появится спонсор — добавлю в IBProvider режим принудительного разделения "параллельных" транзакций по-разным подключениям. О траблах, которые могут последовать за таким режимом — это уже не ко мне, а на форум самого сервера.
Добавлю что имею представление о работе координатора распределенных транзакций MSSQL. И мне не нравится как он работает, но "в истерику" я от этого не в падаю. Упоминаю только потому, что под ним старт транзакции делается в одном потоке, а коммит в другом. Двухфазность его работы в упор не увидел. Может её там и не должно быть, а может это я туплю
---
Причин по которым не сериализуют транзакции друг за другом наверное много. Но я не буду тут гадать какие. И что для получения этих причин надо выпить/покурить. Я знаю только такие.
1. При жестком коммите (который без продолжения) автоматически закрываются курсоры открытых множеств. Если множество не довыбрано, но очень хочется поскорее изменить его (или не его...) содержимое и закоммить — пожалуйста делайте это в отдельной транзакции. Кстати говоря, даже если полностью множество выбрали — блобы и массивы у FB/IB закачиваются отдельными вызовами для которых нужна транзакция (желательно та, в которой получили их дескрипторы). Полагаю, ума хватит не возводить эту особенность в ранг бесконечной ущербности? — здесь только одни преимущества. Если интересно — у меня есть реальный пример.
Из-за блобов и из-за того, что некоторые компоненты доступа могут давать возможность читать их через потоки (типа IStream), нельзя "прям-сразу" коммитить автоматическую транзакцию. То есть если клиент бросил множество (для загрузки которого автоматически стартовали транзакцию), но удерживает указатель на объект чтения BLOB-а из этого множества — транзакция будет продолжать висеть. Потому что для чтения блоба нужна транзакция. За этим следит не сервер, а компоненты доступа / конечный клиент.
Кроме как из множеств, BLOB-ы могут быть получены через OUT-параметр хранимой процедуры. Так что даже если хранимая процедура вернула управление, коммитить её автоматическую транзакцию еще рано. Нужно закачать блобы, а закачка может быть отложена... (в голову пришел забавный сценарий, который я здесь показывал IT-у в 2002(?) году, когда обсуждали ADODB)
В результате, при наличии незавершенной транзакции может появится другая. В отношении MSSQL — и новое подключение, а для IB/FB —
просто еще одна транзакция.
Если этого еще не говорили другие, напомню — что старт и коммит транзакций на FB/IB — это полностью в руках клиентской части. То есть — либо "в руках" компонент доступа, либо "в руках" конечного ПО.
[лично я в своем конечном прикладном ПО не использую автоматические транзакции в принципе. И IBProvider тому подтверждение — по умолчанию там они отключены. Что привело к очень большому числу сообщений (порожденных в том числе и перебежчиками с MSSQL) что провайдер "не работает" если не указать в строке подключения "auto_commit=true" ]
2. Просто не в состоянии проконтролировать и гарантировать что во время работы линейного алгоритма какая-та его настраиваемая часть (то есть та, которая может модифицироваться после сдачи приложения в эксплуатацию — скрипты/внешние компоненты) вдруг не решит, что ей край какие-то (служебные?) данные прочитать в собственной независимой транзакции. А может это вообще изначально по-сценарию так надо. Или это очередной студент, который решил что это круто, или ему, допуская "к телу", не объяснили базовых принципов.
---
Лично мне глубоко по-барабану кто как и чем юзает свою базу данных. Однако мой опыт подсказывает — что даже умудренные опытом люди, снисходительно ссылающиеся на свои промышленныех решения, могут наступить на тривиальные грабли. Типа чтения нескольких связанных записей в транзакции с уровнем изоляции "read-committed". Про "повторяемое чтение" они слышали, но не увязывали со своей задачей. Или делать это вообще в отдельных транзакциях, ненароком наступив на "автокоммитные" грабли. Иногда они возводят в ранг "абсолютной" истины свои идеи, потому что не знают про другие, знают о них "по-наслышке" или просто хотят что-то доказать. Забыв что доказать можно только одно — собственную глупость.
Сам я себя ох...ным экспертом по БД не считаю — использую вещи, уровень которых зачастую неоправдан в какой-то конкретной задаче. Типа всегда и только всегда — явный старт транзакций и изоляция "повторяемое чтение". Как показала жизнь — благодаря этому избежал очень большое число проблем. Однако, сумел придумать и реализовать несколько интересных вещей, которые "зацепили" других людей. Про другие сервера, когда становится интересны конкретные вещи — задаю другим конкретные вопросы. И как правило получаю вполне приличные ответы — без непрекрытого посыла нах.... в MSDN.
Так что, Иван, с кругозором у твоих "оппонентов" все нормально. Полагаю, что со способностью уважать "чужой образ жизни" — тоже.
Просто никто не ожидал, что ты будешь так (умышленно?) тупить. Причем не в профессиональном, а общечеловеческом смысле.
Поэтому, пытаясь хоть как-то и в чем-то найти общие точки, ненароком упоминали вещи, которые, в совокупности с твоим ехидным издевательством над ними, завели обсуждение в глубокую ж... -ие дебри.
Коваленко Дмитрий.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Andyshark, Вы писали:
A>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться?
Понятно — это клиника. Все что я мог сказать по этому поводу — я уже сказал.
Если непонятно, а очевидно непонятно, то значит моих объяснительных способностей недостаточно, в двадцать восьмой раз объяснять что я имел ввиду рассказывая про проблемы ACID в вашем подходе я не намерен.
A>Ну не совсем простую,
Она просто примитивна.
A> Все что я видел в посте, это голословные утверждения "Должно быть так и только так". Очень жаль.
Это говорит лишь о том, что ничего кроме этого ты увидеть там и не хотел.
A> Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.
Моего кругозора достаточно чтобы понять две простые вещи
1. На практике достаточно одного решения, главное чтобы оно работало в заданых граничных условиях.
2. Среди множества возможных решений, логически рассуждая, можно отсечь подмножество неверных, на разбирая каждое из них в подробностях.
A>P.S. И все-таки, VS? Вы на вопрос так и не ответили. Честно скажу — еще одну священную войну я заводить не собираюсь. Клянусь. Мне глубоко по барабану кто на чем пишет. Главное чтобы правильно.
Во-во, главное правильно.
Я потому и не ответил, что меня конечная платформа волнует в достаточно малой степени, я вообще архитектор, мне с чем только не приходится дело иметь.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>С другой — FB-шники, как ты их тут окрестил, по определению не могут упираться в привычный сценарий
Однакож упираются. При этом никто из них так и не смог внятно объяснить зачем.
КД>- потому что на этом сервере этих сценариев — "до-жопы". Хочешь так. Хочешь эдак. Хочешь вообще по-другому.
Собственно, отчасти в этом и проблема. Когда можно делать все, но нет понимания зачем и к чему это может привести, то это хуже чем иметь ограниченый, но понятный набор возможностей.
КД>А кто-то, до текущего момента, эти вопросы (а как?) — вообще не беспокоили — что уместно, то и юзает.
А вот это главная бедулька. Мало того, что делают не задумываясь, так еще и упираются, никого не слушая.
КД>Лично я понимаю и тех и других. И третьих. И тех кто работает в автокоммите — тоже, лентяев и самоубийц, понимаю. Полагаю, за все это время что пытаюсь постичь дао управления сервером базы данных, перепробовал или трогал все.
Я тоже понимаю. Я их всех прекрасно понимаю. И дальше что?
Видишь ли. Мне давно уже не интересны решения которые просто работают. Я могу про такие решания рассказать — индусы отдыхают, при этом вполне рабочие. Заставить работать можно практически все, если не дышать.
Интересны правильные архитектурные решения — стабильные, хорошо масштабируемые и легко сопровождаемые. И я делюсь своим опытом как такие решения получать. Я ни в коем случае никого не заставляю поступать именно так. Я лишь объясняю как делать не следует и почему. Меня можно не слушать, мне вообщем-то все равно, только хамить не надо.
КД>Причин по которым не сериализуют транзакции друг за другом наверное много. Но я не буду тут гадать какие.
То есть, лень задуматься? Или просто не интересно? Тоже забавная позиция, думать лень, но спорить будем до упора.
КД>1. Кстати говоря, даже если полностью множество выбрали — блобы и массивы у FB/IB закачиваются отдельными вызовами для которых нужна транзакция (желательно та, в которой получили их дескрипторы).
То есть, это особенность FB? Возвращаясь к началу спора, в чем тогда MS провинился, если ему это нафиг не уперлось?
КД>В результате, при наличии незавершенной транзакции может появится другая. В отношении MSSQL — и новое подключение, а для IB/FB - КД> просто еще одна транзакция.
Байта ради. Конечный разработчик этого не заметит. С точки зрения производительности и ресурсов — тоже разницы никакой. Это просто особенности внутренней реализации. Так какой смысл обвинять MS что он делает по другому?
КД>Если этого еще не говорили другие, напомню — что старт и коммит транзакций на FB/IB — это полностью в руках клиентской части. То есть — либо "в руках" компонент доступа, либо "в руках" конечного ПО.
Ну это опять-таки проблемы FB, причем конкретные проблемы. Если MS и другие сервера могут себе позволить без этого обойтись, то это не их вина.
КД>2. Просто не в состоянии проконтролировать и гарантировать что во время работы линейного алгоритма какая-та его настраиваемая часть (то есть та, которая может модифицироваться после сдачи приложения в эксплуатацию — скрипты/внешние компоненты) вдруг не решит, что ей край какие-то (служебные?) данные прочитать в собственной независимой транзакции. А может это вообще изначально по-сценарию так надо. Или это очередной студент, который решил что это круто, или ему, допуская "к телу", не объяснили базовых принципов.
Нет никаких проблем вынести настраиваемые части за рамки внутренних транзакций.
КД>Иногда они возводят в ранг "абсолютной" истины свои идеи, потому что не знают про другие, знают о них "по-наслышке" или просто хотят что-то доказать. Забыв что доказать можно только одно — собственную глупость.
Угу. Наблюдал тут недавно, ужас просто Некоторые оппоненты иногда, ну просто как дети..
КД>Так что, Иван, с кругозором у твоих "оппонентов" все нормально. Полагаю, что со способностью уважать "чужой образ жизни" — тоже.
Незнаю-незнаю. Они заставили меня в этом всерьез засомневаться.
Здравствуйте, Ramzzes, Вы писали:
R>Здравствуйте, _d_m_, Вы писали:
___>>Офигеть, дайте две. Здесь вполне можно открыть второе соединение и там выполнить изменения справочника — какая здесь необходимость в параллельных транзакциях?
R>Объясните уж неверным, какое такое офигенное технологическое преимущество мы получаем, открывая в данном случае второе соединение?
А какое офигенное технологическое преимущество мы имеем используя здесь параллельные транзакции?
Я хотел лишь сказать, что в параллельных транзакциях нет необходимостим — вот и все.
Здравствуйте, pnv82, Вы писали:
___>>Офигеть, дайте две. Здесь вполне можно открыть второе соединение и там выполнить изменения справочника — какая здесь необходимость в параллельных транзакциях?
P>А можно не открывать. Какая здесь необходимость в двух соединениях?
А какая необходимость в параллельных транзакциях? Это два никак не связанных, независимых действия.
P>Но самое приятное, что в ФБ я могу как открывать соединения, так и нет — я волен сам решать, что в данном, частном случаем, мне выгоднее(про, например, переменные сессии уже говорилось, причем не один раз....).
Ну приятно ездить на телеге с пятью колесами — на здоровье.
Но что получается? Пассажиры пятиколесной телеги:
— считают, что пятое колесо ну просто офигенное преимущество и технологически продвинутый ход;
— презирают остальных, кто ездит на четырехколесных;
— презирают создателей четырехколесных телег, называя их уродами, а созданый ими интерфейс — убогим;
Здравствуйте, Andyshark, Вы писали:
A>Здравствуйте, IB, Вы писали:
A>Хм. Не понял — мессага не ушла или кто-то снова балуется? Хотя может и браузер глючит, но прецеденты были. Повторюсь тогда.
A>>> Я процитировал на всякий случай. IB>>О чем речь-то? A>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?
Тебе же написали — сырые данные поставляет клиент. Одной рукой он пишет в T1 некие данные, читает что-то там из T1 и второй рукой пишет в T2. С точки зрения T2 эти данные являются сырыми, потому что коммита T1 еще не произошло. Если T1 откатить, а T2 закоммитить, то в базе окажется результат никогда не существовавших вычислений.
Если делать наоборот — в процессе сервировки T1 быстренько выполнить T2, то риск несколько снижается. Но и смысл использовать для T2 то же самое соединение минимален.
Напомню, что логическое соединение — это не только канал, но и набор всяких там настроек. Начиная от контекста пользователя и заканчивая форматом представления даты.
С точки зрения T2, всё происходит в ее личном соединении, потому что использовать тот факт, что в нём же работает T1, она не имеет права — иначе нарушается изоляция.
Поэтому хорошие библиотеки/фреймворки оформляют такие вещи в виде отдельного соединения. Если нижележащий провайдер умеет пулить соединения или даже гонять транзакции по тому же каналу параллельно — честь ему и хвала. Пусть себе делает это там, глубоко под палубой, в машинном отделении. Чтобы капитан, т.е. разработчик, не грел себе голову, что будет, если в процессе работы с T2 вложенный код "починит" текущее значение ANSI_NULLS для соединения, и забудет его вернуть обратно.
A>>> А Вам скольких способов хватает? IB>>Достаточно одного. A>Всем доподлинно известно что любую задачу можно решить минимум 2-3 способами. Причем методики решения могут кардинально отличаться, и все будут давать правильные результаты. Именно поэтому я не могу никогда сказать, что я нашел все доступные способы решения задачи. Ну приучили меня к этому, и это мировоззрение я считаю верным, т.к. человек не бог, и я не бог. Я не могу увидеть все решения задачи, хотя вижу их по 2-3 практически всегда, а частенько и больше. Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону.
Э-эх. Опять классика кун-фу. Очень хорошо, что ты видишь 2-3 решения там, где новичок с трудом находит одно. Но это далеко не последний дан. Предрекаю тебе чувство глубокого отчаяния, которое охватит тебя через годы при попытках объяснить новичкам, почему нельзя делать некоторые вещи, даже если кажется, что они приводят к тому же результату. И ты точно так же будешь говорить "это темная сторона силы", а они будут говорить "нет учитель, есть разные способы".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andyshark, Вы писали: A>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? Или про BDE тоже не в курсе как и про транзакции IB/FB?
Ну я вот, к примеру, присутствовал на презентации BDE, когда он был новым словом во взаимодействии с СУБД. И нахлебался этого дерьма я с избытком. И совершенно с IB согласен, если что.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали: А>А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.
Не надо ничего высчитывть. Вообще удерживать соединения открытыми — моветон. Во времена оны (когда BDE был бодр и весел) это считалось нормальным, но я напомню, что клиент-серверная архитектура (ныне заслуженно считаемая старомодной) тогда была только в проекте. ВDE с самого рождения проектировался для работы с безсерверными СУБД, и в первую очередь с Paradox (а во вторую — со всякими DBase). Интербейз был приклеен сбоку и значительно позже.
Оттуда и эти глупости с перманентно открытыми соединениями и жонглированием транзакциями. Правильный ответ — пулинг кратковременно используемых соединений, и трактовка базы как штуки, которую ты изредка беспокоишь своими просьбами что-то сделать, а не прямым ковырянием в строчках таблиц.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, IB, Вы писали:
IB>>Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>>> Почему там нельзя одновременно стартовать две, три, 5000 транзакций??? IB>>Для того чтобы это делать надо на клиенте заниматься изнурительным многопоточным программированием, разруливая одно соедиение между несколькими потоками. Гораздо проще и надежнее не делать этого.
А>Вы меня извините, но это нонсенс. где тут изнурительное программирование? А> ... А> TR1.StartTransaction; А> ... А> TR2.StartTransaction; А> ... А> TR1.Commit; А> TR2.Rollback;
Отлично. А вы, Дмитрий Валерьевич, между TR2.StartTransaction и TR1.Commit какие-то данные из TR2 в TR1 переносите? Если нет, то что мешает поставить TR2.StartTransaction после TR1.Commit? А если да, то какая же тут нахрен изоляция, если вы в TR1 закоммитили изменения, зависящие от отроллбэканных изменений в TR2? Нонсенс получается, Дмитрий Валерьевич.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andyshark, Вы писали:
A>>Здравствуйте, IB, Вы писали:
A>>Хм. Не понял — мессага не ушла или кто-то снова балуется? Хотя может и браузер глючит, но прецеденты были. Повторюсь тогда.
A>>>> Я процитировал на всякий случай. IB>>>О чем речь-то? A>>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах? S>Тебе же написали — сырые данные поставляет клиент. Одной рукой он пишет в T1 некие данные, читает что-то там из T1 и второй рукой пишет в T2. С точки зрения T2 эти данные являются сырыми, потому что коммита T1 еще не произошло. Если T1 откатить, а T2 закоммитить, то в базе окажется результат никогда не существовавших вычислений.
Я наверное не догоняю, но ткните меня пальцем ГДЕ клиент поставляет мне сырые данные? То что у меня на одной форме два запроса работающих в разных транзакциях (причем один селект, а другой на апдейт к примеру), то где тут сырые данные скажите мне? Первый возвращает гарантировано закоммиченные данные, второй гарантировано пишет. Никаких блокировок тем более не происходит. Если мне они нужны будут на какой-либо записи то я ее сделаю самостоятельно (или помощью запроса соответствуюего, но это уже по мере необходимости). Видно имеет место БОЛЬШОЕ недопонимание логики работы других людей, которые работают с более расширенным функционалом. И хочется загнать их в эти рамки. Кто вам сказал что я не могу использовать оба запроса в одной транзакции? Могу. Но по некоторым причинам не хочу в данном конкретном случае. Кто сказал что я не пользуюсь одной транзакцией для задачи? Я такого не говорил, я пользуюсь. Но в каждом конкретном случае рассматриваю КАК мне лучше сделать доступ к БД. Мало ли какая задача.
Вот кстати еще одна в которой неудобно использовать одну транзакцию:
Есть таблица в которой присутствуют записи должные быть распечатанными один единственный раз на некоторых принтерах (не будем вдаваться в каких, не суть важно). Т.е. в данном конкретном случае мы имеем с одной стороны БД целостность которой должны быть поддержана в любых условиях. С другой стороны повторная печать на принтере не допускается. Т.е. из этой таблицы данные должны удаляться (помечаться на удаление) после печати. Если я стартую все в одной транзакции, то мне туда же надо и запихивать удаление (пометку на удаление), и коммитить после каждой печати запрос на выборку. Ну и как данную задачу решить с одной транзакцией? Легко скажете? А не легче ли стартовать snapshot транзакцию и не париться? Зачем лишний геморой? Я наверное не понимаю.
A>>Всем доподлинно известно что любую задачу можно решить минимум 2-3 способами. Причем методики решения могут кардинально отличаться, и все будут давать правильные результаты. Именно поэтому я не могу никогда сказать, что я нашел все доступные способы решения задачи. Ну приучили меня к этому, и это мировоззрение я считаю верным, т.к. человек не бог, и я не бог. Я не могу увидеть все решения задачи, хотя вижу их по 2-3 практически всегда, а частенько и больше. Если у Вас кругозор такой что Вы видите только одно решение задачи, и железно уверены что оно ЕДИНСТВЕННО верное, то грош Вам цена как программисту. IMHO. Поэтому про кругозор немного не в ту сторону. S>Э-эх. Опять классика кун-фу. Очень хорошо, что ты видишь 2-3 решения там, где новичок с трудом находит одно. Но это далеко не последний дан. Предрекаю тебе чувство глубокого отчаяния, которое охватит тебя через годы при попытках объяснить новичкам, почему нельзя делать некоторые вещи, даже если кажется, что они приводят к тому же результату. И ты точно так же будешь говорить "это темная сторона силы", а они будут говорить "нет учитель, есть разные способы".
Вау. Бог и иже с ним. Я свою позицию по этому вопросы высказал. Проблема в том что Вы не хотите встать на позицию оппонента. Мне вас по человечески жаль.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andyshark, Вы писали: A>>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? Или про BDE тоже не в курсе как и про транзакции IB/FB? S>Ну я вот, к примеру, присутствовал на презентации BDE, когда он был новым словом во взаимодействии с СУБД. И нахлебался этого дерьма я с избытком. И совершенно с IB согласен, если что.
Хм. А я где-то говорил что я СТОРОННИК BDE? Но я сторонник того что идея то была более-менее хорошая. Если бы она была совсем дерьмовая, то она бы уже давно умерла. Или вы считаете всех кто пользует BDE придурками и дерьмохлебами? Сразу скажу — я BDE уже сто лет не пользую, ну не сnоронник я ее в чистом виде. Но для своего времени это было очень даже и неплохо. Можете отделить идею от реализации? И учетом того КОГДА идея была сделана?
Мы уже победили, просто это еще не так заметно...
