Здравствуйте, IB, Вы писали: IB>Давай откроем учебник — транзакция это совокупность операций по переводу данных из одного согласованного состояния в другое. Где и как это происходит совершенно не важно. Для того, чтобы процесс сошелся и перевод произошел именно в согласованное состояние, должны соблюдаться требования ACID. IB>Ты серьезно думаешь, что если требоания ACID нарушатся на клиенте, а не на сервере БД, то в конечном итоге данные окажутся в более согласованном состоянии?
Тоесть, ты хочешь сказать, что не один сервер баз данных не выполняет требования ACID?
Ведь для любого сервера можно написать клиента, который их нарушит.
Здравствуйте, Пацак, Вы писали:
П>Да почему нельзя-то?
Я объяснил почему. Если до сих пор непонятно, то я бессилен.
П>Нельзя считать подобные действия единой атомарной изолированной транзакцией — это да, но если бизнес-процессом такой цели и не ставится, то почему нет?
Потому что атомарная изолированная транзакция — очень удобная абстракция для описания бизнес-процесса. И вместо того чтобы обходить, надо этим пользоваться.
П> И наоборот — кто мешает не делать так на Fb, если это действительно необходимо?
У FB-шников правда что ли комплекс какой? речь уже давно не про FB, а про архитектуру клиента.
П> Возможность есть, а пользоваться ей или нет — это уж каждый для себя решает сам, в каждом конкретном случае.
Эта возможность есть везде, но почему-то на других серверах это никому в голов не приходит.
Здравствуйте, Tonal-, Вы писали:
T>Тоесть, ты хочешь сказать, что не один сервер баз данных не выполняет требования ACID?
Сервер БД здесь не причем.
T>Ведь для любого сервера можно написать клиента, который их нарушит.
Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.
Здравствуйте, Andyshark, Вы писали:
A> Кто-то пользуется Вашим именем?
Кто-то посмел?
A>В данном конкретном случае UI пересекается с конкретной задачей.
Не пересекается ни в одном месте.
A>А в какую сторону у нас двигаются сейчас разработки? Что СУБД что языков программирования.
Могу лекцию прочитать, надо?
A>Вот именно что не представляю.
Пора уже расширять кругозор.
Здравствуйте, Andyshark, Вы писали:
A>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась?
То есть, проблема в том, что BDE изначально задумывалась кривой, потому что создавалась очень давно?
Ну и что после этого валить с больной головы на здоровую?
A> Или про BDE тоже не в курсе как и про транзакции IB/FB?
Ну, сдается мне, что в BDE я разбираюсь лучше, чем все защитники FB в транзакциях, оптом..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Tonal-, Вы писали:
T>>Тоесть, ты хочешь сказать, что не один сервер баз данных не выполняет требования ACID? T>>Ведь для любого сервера можно написать клиента, который их нарушит. IB>Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.
Хорошо, если пльзователь увидел цифирь которую прога получиа в одной транзакции, и в соответствии с ней изменил данные в другой транзакции — это как расценивать?
Мне всегда казалось, что ACID — это гарантии именно сервера относительно данных.
И пока клиент не лезет в "нутро" сервера, а пользуется педоставленными ему интерфейсами, он может расчитывать на их выполнение.
А если пользуясь только стандартными средствами клиент может в лёгкую нарушить эти гарантии сервера, то стало быть и нет никаких гарантий.
Если рассмотреть твой ответ, то ни один снервер просто не в состоянии предоставить эти самые гарантии, что бы не написал разработчик.
Здравствуйте, IB, Вы писали:
IB>Потому что атомарная изолированная транзакция — очень удобная абстракция для описания бизнес-процесса.
Удобный != единственный. Строго говоря даже атомарность самого клиента не является необходимым условием — я, например, знаю систему, где приятие решения о допуске пользователя к выполнению некоего действия, определение параметров этого действия и собственно производство этого действия выполнялись тремя независимыми друг от друга приложениями. И как ты в этом случае предлагаешь посредством изолированности и атомарности их транзакций поддерживать непротиворечивость бизнес-процесса?
T>>Ведь для любого сервера можно написать клиента, который их нарушит. IB>Можно. Но почему-то тем кто работает с другими серверами такое в голову не приходит.
Очень спорное утверждение. Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы. Никаких фатальных последствий, кроме неудобства, это правда афаир не вызывало, но тем не менее...
A>3. Задача в которой надо открывать 2 окна для работы с разными данными была описана (в одном отфетченный список клиентов например, в другом окне надо отредактировать какие-то данные про этого клиента)
в оракле поправить справочник можно в той же конекции в автонономной транзакции.
П>Очень спорное утверждение. Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы. Никаких фатальных последствий, кроме неудобства, это правда афаир не вызывало, но тем не менее...
нормальная практика hibernate — кешировать справочники на апп-сервере
Здравствуйте, IB, Вы писали:
P>>Если я правильно понял то, о чем ты хотел сказать своим примером. IB>Нда.. не правильно. IB>Своим примером я хотел сказать, что даже для версионника длинные транзации- не сахар.
Непраивльный пример. Он этого совершенно не показывает.
(будем общаться в вашем стиле).
P>>Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился? IB>Нет. P>>Только вот какое отношение это все имеет к поднятому вопросу? IB>Самое прямое. Я тут уже который раз вдалбливаю тривиальную истину, о том что свойство изолированности придумали не просто так и не следует обходить его через клиента.
Ппц, я что, в пустоту говорю? Кто ее обходит? Из чего такой вывод?
Я привел пример, демонстрирующий удобство использования двух параллельных транзакций — какие обходы изолированности, Иван, окститесь!
P>> Об этом вам говорят люди пробовавшие ОБА подхода. IB>В том-то и проблема, что об этом говорят люди пробовавшие только один подход, более того, судя по обилию и разнообразию примеров — только один тип приложений.
Эээ, ну еси это было не ясно — Я. ИСПОЛЬЗОВАЛ. ОБА. ПОДХОДА.
В разных типах приложений. И буду использовать дальше оба. Ибо в каждом случае, могу выбирать, что мне удобнее и выгоднее. Чего и все рекомендую.
Здравствуйте, _d_m_, Вы писали:
P>>В какой-то момент времени, пользователь видит, что в справочнике номенклатуры ошибка — он открывает карточку соответствующего товара, и в транзакции Т2 исправляет название, после чего коммитит Т2. Заметим, эти изменения справочника должны остаться в БД, даже если пользователь откатит Т1. И только по завершению редактирования документа комитится Т1. P>>Т1 и Т2 как раз и есть, то, что называют параллельными транзакциями в этой ветке. ___>Офигеть, дайте две. Здесь вполне можно открыть второе соединение и там выполнить изменения справочника — какая здесь необходимость в параллельных транзакциях?
А можно не открывать. Какая здесь необходимость в двух соединениях?
Но самое приятное, что в ФБ я могу как открывать соединения, так и нет — я волен сам решать, что в данном, частном случаем, мне выгоднее(про, например, переменные сессии уже говорилось, причем не один раз....).
Здравствуйте, IB, Вы писали:
A>> Кто-то пользуется Вашим именем? IB>Кто-то посмел?
Если нет? то Вы сами себе противоречите. Мне пишите одно, а другим другое. Или у;е не помните что писали? Я процитировал на всякий случай.
A>>А в какую сторону у нас двигаются сейчас разработки? Что СУБД что языков программирования. IB>Могу лекцию прочитать, надо?
Да толку то. Хотя попробовать можно. Может статью напишите? Тогда флейма не будет просто еще по одному вопросу.
A>>Вот именно что не представляю. IB>Пора уже расширять кругозор.
Сами ратуете за то чтобы расширяли кругозор, а простую истину понять не можете.... Тогда поясняю — одну задачу можно решить множеством способов. И сами способы решения зависят в основном от мышления каждого конкретного человека. Поэтому я НЕ ПРЕДСТАВЛЯЮ сколькими способами можно решить задачу. Я просто не бог. Могу привести решение любой задачи 3-4 способами стабильно. Мне этого хватает. А Вам скольких способов хватает?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Andyshark, Вы писали:
A>>Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? IB>То есть, проблема в том, что BDE изначально задумывалась кривой, потому что создавалась очень давно? IB>Ну и что после этого валить с больной головы на здоровую?
Ну если такой подход к BDE, то вопрос закрыт. Программите на VS наверное?
A>> Или про BDE тоже не в курсе как и про транзакции IB/FB? IB>Ну, сдается мне, что в BDE я разбираюсь лучше, чем все защитники FB в транзакциях, оптом..
Ну и отлично Я рад что есть такой специалист.
Здравствуйте, pnv82, Вы писали:
P>Непраивльный пример.
Ну я не виноват, что он тебе не нравится.
P> Кто ее обходит? Из чего такой вывод?
я уже устал писать из чего такой вывод. Перечитай топик, внимательно.
P>Я привел пример, демонстрирующий удобство использования двух параллельных транзакций
А я показал, что на самом деле две параллельные транзакции там не нужны.
P>Эээ, ну еси это было не ясно — Я. ИСПОЛЬЗОВАЛ. ОБА. ПОДХОДА.
Зачем? Какую задачу ты решал используя две активные транзакции из одного подключения и что мешало сериализовать эти транзакции?
P>И буду использовать дальше оба.
Ну и зря, тем более оба.
Здравствуйте, Andyshark, Вы писали:
A> Я процитировал на всякий случай.
О чем речь-то?
A>Да толку то. Хотя попробовать можно. Может статью напишите? Тогда флейма не будет просто еще по одному вопросу.
Да я уже десяток статей написал..
A>Сами ратуете за то чтобы расширяли кругозор, а простую истину понять не можете.
Проблема похоже в том, что я простую мысль объяснить не могу..
A> А Вам скольких способов хватает?
Достаточно одного.
Здравствуйте, Andyshark, Вы писали:
A>Ну если такой подход к BDE, то вопрос закрыт.
Ну слава байту, хоть с одним разобрались.
A>Ну и отлично Я рад что есть такой специалист.
А я-то как..
Здравствуйте, Tonal-, Вы писали:
T>Мне всегда казалось, что ACID — это гарантии именно сервера относительно данных.
Ты ошибался.
T>Если рассмотреть твой ответ, то ни один снервер просто не в состоянии предоставить эти самые гарантии, что бы не написал разработчик.
Даже не рассматривая моего ответа должно быть очевидно, что при должной ловкости рук можно обойти любую систему. Но это вовсе не значит, что это нужно делать.
Здравствуйте, Пацак, Вы писали:
П> Удобный != единственный.
Кто бы спорил. Способов прострелить себе ногу пытаясь повеситься более чем достаточно.
П> я, например, знаю систему, где приятие решения о допуске пользователя к выполнению некоего действия, определение параметров этого действия
Это проблемы исключительно этой системы.
П> Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы.
И что же в этом примере обратного?
Здравствуйте, IB, Вы писали:
IB>Кто бы спорил. Способов прострелить себе ногу пытаясь повеситься более чем достаточно.
Слова, слова...
IB>Это проблемы исключительно этой системы.
Что делать, такая вот уж плохая система, бывает иногда, что требуются и такие. Но факт в том, что большая часть бизнес-процессов в ней не удовлетворяла требованиям ACID даже близко, не говоря уж о какой-то золотой пуле в виде правила "одно действие — один коннект". Тем не менее, несмотря на всю свою "идеологическую неправильность" система работала и полностью удовлетворяла заказчика (*). Не вижу причин, почему бы других заказчиков не должны удовлетворить обсуждаемые здесь параллельные транзакции, которые при правильном использовании гораздо более безопасны и надежны, чем описаная модульная мешанина.
П>> Из наиболее вопиющих примеров обратного вспоминается оракловая прога, которая при старте вычитывала на клиента справочники и пользовалась ими без перечитывания вплоть до самого завершения работы. IB>И что же в этом примере обратного?
В выделеном. Кто-то утверждал, что использование данных транзакции А в транзакции Б — это исключительно firebird-заморочки, насколько мне помнится, а настоящим крутым чувакам такое-де и в голову прийти не может. Однако же приходит, как ни странно, и при том весьма регулярно.
(*) Да, кстати — эта система тоже использовала не firebird.
Здравствуйте, IB, Вы писали:
P>>Непраивльный пример. IB>Ну я не виноват, что он тебе не нравится.
Ну, а кто же еще виноват? Ты говоришь про какую-то систему, на Оракле, с неизвестной архитектурой и внутренностями, СЕРИАЛИЗОВАННЫМИ, вследствии архитектуры Оракла, транзакциями — привязать этот пример к теме топика можно лишь дофантазировав удобные тебе детали — технических фактов 0. Приведи, плз, подробности архитектуры той системы — что делают в той длинной транзакции, как там выполняются параллельные действия и т.п. Т.е. свяжи свой пример с темой.
P>> Кто ее обходит? Из чего такой вывод? IB>я уже устал писать из чего такой вывод. Перечитай топик, внимательно.
Дурь ты всякую написал, прости за резкость. Даже теоретически нигде изолированность там не нарушается,
если транзакции уровня RC. А читая твои посты — появляется подозрения, что с уровнями изолированности ты знаком слабо — но боюсь показаться излишне самоуверенным и наглым — давай вместе перечитаем документацию, и еще раз, ВНИМАТЕЛЬНО, посмотрим, как и где, в моем примере, нарушается изолированность транзакций.
P>>Я привел пример, демонстрирующий удобство использования двух параллельных транзакций IB>А я показал, что на самом деле две параллельные транзакции там не нужны.
??? А никто и не говорил, что они там необходимы, или обязательны — они возможны и удобны.
О чем, собсно, и начинался топик.
P>>Эээ, ну еси это было не ясно — Я. ИСПОЛЬЗОВАЛ. ОБА. ПОДХОДА. IB>Зачем? Какую задачу ты решал используя две активные транзакции из одного подключения и что мешало сериализовать эти транзакции?
Гм, мне что, в подпись вставить свои пример?
Скажи, ты ведь использовал где-либо схему с несколькими подключениями на одного клиента? Так вот, грубо говоря, там же я использовал одно подключение, но с несколькими транзакциями(напоминаю, это утрированный пример — там где реально нудно несколько подключений, например в сервере приложений, естественно пользуются раздельные подключения)
P>>И буду использовать дальше оба. IB>Ну и зря, тем более оба.
Нда, всегда считал, что модераторов назначают людей с достаточно широким кругозором и большим опытом. К моему удивлению ты показываешь обратные качества — не разобравшись в вопросе, публично делать такие выводы?
Есть идея, давайте четко сформулируем предмет спора, и каждая сторона напишет статью по теме — ибо я не вижу, как иначе прекратить передергивания и неаргументированные заявления.
Мы уже победили, просто это еще не так заметно...
