Привет, IB!
Вы пишешь 21 сентября 2007:
R>> Если знаете, тогда объясните пожалуйста, какие в нем могут быть незафиксированные данные? I> Очень просто. Фетчим данные на клиента, потом их меняем (те, которые отфестчили на клиента — I> неужели это так сложнопонять?), потом этими измененными данными пользуется другая транзакция.
Иван, а вот ежели я тебе скажу: "иногда лучше жевать, чем говорить!", ты меня забанишь?
Интересно просто. А то некий kuj тут так и мелькает с этой фразой, так и мелькает...
Иван, какое отношение имеют данные отфетченные на клиента, к состоянию транзакии?
Подтвержденные, неподтверждённые...
Проясни.
I> Я утверждаю, что способ X — не кошерный, вне зависимости от сервера. I> Почему — я пытался объяснить неоднократно. Возможно несколько коротко
Дык, где же, где же?
Наводящие вопросы ты игнорируешь напрочь.
Аргументов никаких, одни эммоции...
I> но ребята объяснений было более чем достаточно и вообще я уже сутки как в отпуске.
Здравствуйте, Andyshark, Вы писали:
A>Вообще почитал, и мне стало интересно — а те кто пишут про просмотр "незакомиченных" данных при обычном селекте хоть что-нибудь про транзакции IB/FB знают или нет?
Ты точно читал? все читал? внимательно-внимательно читал?
Еще раз, на пальцах, следи за руками:
Транзакции изолированы, IB, как и все приличные серваки, всеми силами пытается недопустить чтобы сырые данные одной транзакции не увидела другая. Но народ собирается читать данные из одной транзакции на клиента и дать другой транзакции эти данные. На клиенте эти данные может поменять кто угодно и сервер это уже не отследит и вся изолированность "идет лесом" (с). Именно по этой причине так делать нельзя.
Здравствуйте, Alex.Che, Вы писали:
AC>Иван, а вот ежели я тебе скажу: "иногда лучше жевать, чем говорить!", ты меня забанишь?
Еще разок и да, пора банить. И вообще еще один впад не по делу и ветка во флейм, мне отдыхать надо.
AC>Интересно просто. А то некий kuj тут так и мелькает с этой фразой, так и мелькает...
Не, ребята, ваша фракция по очкам вне конкуренции.
AC>Иван, какое отношение имеют данные отфетченные на клиента, к состоянию транзакии?
Ты считаешь что если данные уехали на клиента то это уже вроде ка ки не транзакция?
AC>Подтвержденные, неподтверждённые... Проясни.
Да я уже устал пояснять, ей богу.
Вот если вечерком будет время может напишу развернуто, если вы меня окончательно не озлобите..
AC>Дык, где же, где же?
В ветке.
AC>Наводящие вопросы ты игнорируешь напрочь.
Я?!! Да это вы не наодин мой вопрос ответить не можете, вам почему-то сразу кажется, что обижают ваш любимый IB.
AC>Аргументов никаких, одни эммоции...
РЕбят, вы хотя бы себя читате? Про меня я уже даже не спрашиваю, но в ваших ответах хотя бы иногда попадаются мои цитаты..
AC>Слив засчитан.
Озлобил.
[Sorry, skipped] AC>> Иван, какое отношение имеют данные отфетченные на клиента, к состоянию транзакии? I> Ты считаешь что если данные уехали на клиента то это уже вроде ка ки не транзакция?
Иван, транзакция живет на сервере.
Что там у клиента за щекой — серверу не интересно.
AC>> Подтвержденные, неподтверждённые... Проясни. I> Да я уже устал пояснять, ей богу. I> Вот если вечерком будет время может напишу развернуто, I> если вы меня окончательно не озлобите..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Andyshark, Вы писали:
A>>Вообще почитал, и мне стало интересно — а те кто пишут про просмотр "незакомиченных" данных при обычном селекте хоть что-нибудь про транзакции IB/FB знают или нет? IB>Ты точно читал? все читал? внимательно-внимательно читал?
Очень-очень внимательно и весь пост.
IB>Еще раз, на пальцах, следи за руками: IB>Транзакции изолированы, IB, как и все приличные серваки, всеми силами пытается недопустить чтобы сырые данные одной транзакции не увидела другая. Но народ собирается читать данные из одной транзакции на клиента и дать другой транзакции эти данные. На клиенте эти данные может поменять кто угодно и сервер это уже не отследит и вся изолированность "идет лесом" (с). Именно по этой причине так делать нельзя.
1. Сырые данные в IB/FB ты никак не прочитаешь. Если уверен что сможешь то RTFM по IB.
2. Есть идеальный мир и есть реальный. В реальном программисты работают для клиентов и им за это платят деньги. Т.е. любой программист должен работать и делать удобный интерфейс для клиента.
3. Задача в которой надо открывать 2 окна для работы с разными данными была описана (в одном отфетченный список клиентов например, в другом окне надо отредактировать какие-то данные про этого клиента)
Если следовать вашей логике, то надо закрыть список клиентов и потом открыть карточку клиентов в отдельном окне. Потом снова открыть список клиентов и продолжать работать. Клиенту использующему Вашу программу далеко по барабану как там внутри все работает, ему важно удобство. И IB/FB предлагает сделать это с минимальными затратами для программиста.
P.S. Может я немного утрировал сам процесс, но так более понятно думаю. Или есть варианты?
Здравствуйте, IB, Вы писали:
SM>> И тебе пытались объяснить на примерах, как можно сделать. IB>Ты так и не понял, что тебе пытались объяснить почему так делать нельзя.
Объяснения методом выборочного удаления сообщений — это что-то новенькое
А вот на мессагу с демкой почему-то ответа никакого...
Может на ее примере ещё раз попробуем? Тута
Здравствуйте, SmlMouse, Вы писали:
SM>Объяснения методом выборочного удаления сообщений — это что-то новенькое
Ни одного сообщения, где было хоть что-то по делу удалено не было.
SM>А вот на мессагу с демкой почему-то ответа никакого...
потому что демка не по делу, да и времени нет.
SM>Может на ее примере ещё раз попробуем?
Давай пример.
Здравствуйте, Alex.Che, Вы писали:
AC>Иван, транзакция живет на сервере.
Нда.. И эти люди говорят мне об огарниченности мышления и закостенелости взглядов..
Давай откроем учебник — транзакция это совокупность операций по переводу данных из одного согласованного состояния в другое. Где и как это происходит совершенно не важно. Для того, чтобы процесс сошелся и перевод произошел именно в согласованное состояние, должны соблюдаться требования ACID.
Ты серьезно думаешь, что если требоания ACID нарушатся на клиенте, а не на сервере БД, то в конечном итоге данные окажутся в более согласованном состоянии?
AC>Что там у клиента за щекой — серверу не интересно.
Вот собственно в этом и проблема. Именно эту простую мысль я и пытаюсь до вас донести. Если вы обойдете сервер и начнете обмениваться данными активных транзакций между собой, то сервер уже не сможет этот обмен проконтролировать.
AC>Ждем-с.
Тогда бросайте хамить.
Мы уже победили, просто это еще не так заметно...
Re[11]: А может вообще уйти с Firebird?
От:
Аноним
Дата:
21.09.07 20:50
Оценка:
Здравствуйте, IB, Вы писали:
IB>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении? IB>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.
Абисняю. Все ОЧЕНЬ ПРОСТО.
Есть один TDatabase на приложение.
В каждой форме где есть запросы есть как минимум одна транзакция. она стартуется/коммитится в соответствии в логикой работы запросов на этой форме. И меня совершенно не волнует при этом что какой-то другой модуль может что-то сделать с транзакией этой формы — потому что они просто ее не видят
На всякий случай поясню — приложение однопоточное, в автокриэйте всего пара форм, остальные создаются при открытии окна и потом уничтожаются. Окна есть как модальные так и MDIChild.\
А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.
Здравствуйте, Andyshark, Вы писали:
A>Очень-очень внимательно и весь пост.
Надо не пост читать, а ветку.
A>1. Сырые данные в IB/FB ты никак не прочитаешь. Если уверен что сможешь то RTFM по IB.
... нет слов. Сколько раз надо сказать, что речь не про FB и его уровни изоляции, а про то как эти уровни изоляции пытаются обойти на клиенте?
A>2. Есть идеальный мир и есть реальный. В реальном программисты работают для клиентов и им за это платят деньги. Т.е. любой программист должен работать и делать удобный интерфейс для клиента.
За интерфейсом для клиента — к UI дизайнерам, здесь же немного другой форум.
A>Клиенту использующему Вашу программу далеко по барабану как там внутри все работает,
Только при условии, что все работает без ошибок.
A> И IB/FB предлагает сделать это с минимальными затратами для программиста.
Ну да, а то перенапряжется — бедолага.
A>Или есть варианты?
Ты даже не представляешь сколько.
Здравствуйте, Аноним, Вы писали:
А>Абисняю. Все ОЧЕНЬ ПРОСТО. А>Есть один TDatabase на приложение.
... А>А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.
То есть, проблема в том, что борланд не смог написать правильную клиентскую библиотеку?
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, IB, Вы писали:
IB>>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении? IB>>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.
А>Абисняю. Все ОЧЕНЬ ПРОСТО. А>Есть один TDatabase на приложение. А>В каждой форме где есть запросы есть как минимум одна транзакция. она стартуется/коммитится в соответствии в логикой работы запросов на этой форме. И меня совершенно не волнует при этом что какой-то другой модуль может что-то сделать с транзакией этой формы — потому что они просто ее не видят
С чьей, простите, транзакцией?
Неужели кто-то еще пользуется продуктами Borland?
Тут, понимаешь, повсеместное DDD, OR/M, IoC ... а у Вас формочки мучаются несварением транзакций...
Здравствуйте, kuj, Вы писали:
R>>Объясните уж неверным, какое такое офигенное технологическое преимущество мы получаем, открывая в данном случае второе соединение?
kuj>Бритву Оккама
Здравствуйте, IB, Вы писали:
IB>Ты серьезно думаешь, что если требоания ACID нарушатся на клиенте, а не на сервере БД, то в конечном итоге данные окажутся в более согласованном состоянии?
Иван, это передергивание. Для того, чтоб "обойти ACID" на клиенте наличия двух одновременных транзакций не требуется — достаточно просто запомнить состояние одной из них.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Аноним, Вы писали:
А>>Абисняю. Все ОЧЕНЬ ПРОСТО. А>>Есть один TDatabase на приложение. IB>... А>>А вот помнится когда я писал под тот же IB через BDE где есть ограничение один коннект — одна транзакция — вот это была блин песня. Страшный сон. Надо высчитывать сколько же понадобится коннектов, какого типа там буду транзакции, в итоге у меня было 4 коннекта (и соответственно 4 транзакции) — 2 на работу со справочниками и 2 — на раоту с документами. По 2 — что бы можно было удерживая холостым Update делать что-то еще.
IB>То есть, проблема в том, что борланд не смог написать правильную клиентскую библиотеку?
Хм.... А Вы про BDE что знаете? Дату выпуска первой версии, для чего создавалась? Или про BDE тоже не в курсе как и про транзакции IB/FB?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Andyshark, Вы писали:
A>>Очень-очень внимательно и весь пост. IB>Надо не пост читать, а ветку.
Сорь, описАлся.
A>>1. Сырые данные в IB/FB ты никак не прочитаешь. Если уверен что сможешь то RTFM по IB. IB>... нет слов. Сколько раз надо сказать, что речь не про FB и его уровни изоляции, а про то как эти уровни изоляции пытаются обойти на клиенте?
Кто-то пользуется Вашим именем? КДВ>в IB/FB транзакции реализованы в соответствии со стандартом и требованиями ACID. IB> Нет, они не соответствуют стандарту, если уж на то пошло.
A>>2. Есть идеальный мир и есть реальный. В реальном программисты работают для клиентов и им за это платят деньги. Т.е. любой программист должен работать и делать удобный интерфейс для клиента. IB>За интерфейсом для клиента — к UI дизайнерам, здесь же немного другой форум.
В данном конкретном случае UI пересекается с конкретной задачей.
A>>Клиенту использующему Вашу программу далеко по барабану как там внутри все работает, IB>Только при условии, что все работает без ошибок.
Это по моему постулат, и передергивать совсем не надо не в ту сторону.
A>> И IB/FB предлагает сделать это с минимальными затратами для программиста. IB>Ну да, а то перенапряжется — бедолага.
А в какую сторону у нас двигаются сейчас разработки? Что СУБД что языков программирования.
A>>Или есть варианты? IB>Ты даже не представляешь сколько.
Вот именно что не представляю.
Здравствуйте, Пацак, Вы писали:
П>Иван, это передергивание.
Нет.
П> Для того, чтоб "обойти ACID" на клиенте наличия двух одновременных транзакций не требуется — достаточно просто запомнить состояние одной из них.
Ооох.. Я где-то говорил, что в этом виновата только одновременная транзакция?!! Ясен байт, что ничто не мешает так сделать на любом другом сервере. Я лишь утверждал что так делать нельзя, а уж какой сервер и каким способом нагибают, из одного подключения или нет — не важно.
Здравствуйте, IB, Вы писали:
П>> Для того, чтоб "обойти ACID" на клиенте наличия двух одновременных транзакций не требуется — достаточно просто запомнить состояние одной из них. IB>Ооох.. Я где-то говорил, что в этом виновата только одновременная транзакция?!! Ясен байт, что ничто не мешает так сделать на любом другом сервере. Я лишь утверждал что так делать нельзя, а уж какой сервер и каким способом нагибают, из одного подключения или нет — не важно.
Да почему нельзя-то? Нельзя считать подобные действия единой атомарной изолированной транзакцией — это да, но если бизнес-процессом такой цели и не ставится, то почему нет? И наоборот — кто мешает не делать так на Fb, если это действительно необходимо? Возможность есть, а пользоваться ей или нет — это уж каждый для себя решает сам, в каждом конкретном случае.
Мы уже победили, просто это еще не так заметно...
