Re: Немного флейма. Транзакции
"Serge Buzadzhy" ... Vlad Khorsun пишет: "Dmitri Kuzmenko" ... тут ведь еще есть вот какой момент. Любовь к "параллельным" транзакциям пошла из-за того, что BDE БДЕ по моему дофетчивало втихую. Угу. Но БДЕ писалось во времена, когда клиент-сервер только начинал входить в массы и толком было не понятно как с ним работать. Т.е. теоритически все всё знали и понимали, а вот практических навыков (по крайней мере в Б) не было. >>а потом и FreeIBComponents, и IBX/FIBPlus убивают кэш в датасетах, >>т.е. "закрывают запросы". Ну... запрос закрыть это один вопрос. Второй вопрос это кэш в датасетах. Запрос закрыть необходимо. Он просто перестает быть валидным при закрытии транзакции в рамках которой был открыт. Что собственно и понятно. А при чём тут мои локальные, с таким трудом отфетченные, данные ? Знать бы ещё - нафига они это делают... Наша песня хороша - начинай сначала :) Обсуждали ужо. Значит я пропустил тот раз ;) Хочешь - обсудм еще раз. Как скажешь ;) Скажу сразу - это камень не в твой огород, а скорее в огород Грегори Недофетченный запрос, чего с ним делать при закрытии транзакции? А что - надо что-то делать ? Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять недофетченным тоже плохо. Чем ? Тем что бедненький кодер испугается ошибки, которую выдаст злобный сервер при попытке фетча из закрытого курсора ? Ай, как его жалко Оба варианта плохи еще тем что девелопер вообще может не заметить, что что-то делается без его ведома. А вот не надо ничего делать без его ведома. Не надо. Это так просто :) Проблема вообще может всплыть, когда девелопер прогу юзеру отдал. Посему датасет и закрываем, уж этого-то не заметить нельзя, так что девелопер вынужден решать сию проблему вовремя... а не тогда когда она вдруг всплывет. Конечно - мы же лучше знаем, что девелоперу нужно на самом деле... Конкретно эту проблему считаю высосанной их пальца и навязанной множеству кодеров, которые просто слепо верят в инструмент и не задумываются причинах. ЗЫ. Кстати в FIBPlus ( а может и в ИБХ) если датасет в режиме CachedUpdates то при закрытии транзакции, датасет все-таки не закрывается, а дофетчивается. Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и не имею проблем с нижележащими уровнями вообще :) -- Хорсун Влад
Re: Немного флейма. Транзакции
Привет, Vlad! Вы пишешь 20 сентября 2007: [Sorry, skipped] VK> А вот не надо ничего делать без его ведома. Не надо. Это так просто :) Аааа!! Ты знал!!! Ты знал :))) -- With best regards, Alex Cherednichenko.
Re: Немного флейма. Транзакции
Vlad Khorsun wrote: Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и не имею проблем с нижележащими уровнями вообще :) CDS я тоже лублу, вот только оно хорошо когда примерно знаешь сколько ему там фетчить. А то ведь может и не войти в крынку-то. А парцайками тягать муторно. Правда меня это тоже отродясь не волновало, ибо с малолетства разделял пишущие и читающие транзакции. Лично мне текущее поведение внучков Грегори представляется более логичным и простым в использовании чорным ящиком, нежели борьба с недофетченными курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, отсутствием конфликтов модификации там, где они должны быть. Может, конечно, дело привычки... -- Regards. Ded.
Re: Немного флейма. Транзакции
"Ded" ... Vlad Khorsun wrote: Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и не имею проблем с нижележащими уровнями вообще :) CDS я тоже лублу, вот только оно хорошо когда примерно знаешь сколько ему там фетчить. А то ведь может и не войти в крынку-то. А Может у мну (с) крынка резиновая, но никогда на это не напарывался. Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ? Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко, но иногда бывает и такое). Это при том, что есть и более быстрые in-memory таблицы, чем CDS. Да и менее глючные тоже, надеюсь, есть :) парцайками тягать муторно. Правда меня это тоже отродясь не волновало, ибо с малолетства разделял пишущие и читающие транзакции. Лично мне У меня это тоже две разные тр-ции. Но только для того, чтобы дать им (возможно) разный набор параметров, а не для обхода проблемы закрытия датасетов. текущее поведение внучков Грегори представляется более логичным и простым в использовании чорным ящиком, нежели борьба с недофетченными курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, отсутствием конфликтов модификации там, где они должны быть. Может, конечно, дело привычки... Поведение _может_ быть настраиваемым, но не _должно_ быть железобетонно- непробиваемым в стиле : "ты туда не ходи, ты сюда ходи... и только сюда" Я, с точки зрения пользователя компонент, не вижу ничего логичного и простого в закрытии всех датасетов по окончании тр-ции. Наооброт - это приводит в недоумение и заставляет _бороться_ с компонентами\сервером вместо решения моих собственных прикладных задач. -- Хорсун Влад
Re: Немного флейма. Транзакции
Vlad Khorsun wrote: Может у мну (с) крынка резиновая, но никогда на это не напарывался. Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ? Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко, но иногда бывает и такое). Десятки тысяч не проблема. У меня в филиальской briefcase справочной подсистеме десятками и тягается. С тех пор, как наладил репликацию изменией в базовых справочниках и сборку визуализации на месте из засасываемых оперативных числовых данных и названий в локальной базе, вполне шустренько так летает. А вот спервоначалу, когда отправлял туда резалтсет джойна из центра, в какой-нить Тюмени на модеме минут 40 могло грузиться. То есть, к работе с кеширующими фулл фетч датасетами в общем случае надо технологически подходить не как к клиент-серверу. А это не всегда хорошо. Про работу с миллионными архивами, которые в клиент-сервере до конца вообще практически никогда не дофетчиваются, я уж молчу. И никаких специальных приседаний с IBX/FIBPlus для этого не надо, технология на это и заточена. Наоборот, надо приседать, когда нужны отступления от этой технологии. Мы с тобой приседаем при помощи CDS, а Серж строит настраиваемые гибриды с локальными сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и гвоздодёр отдельно и хвататься за то, что нужно в конкретный момент. парцайками тягать муторно. Правда меня это тоже отродясь не волновало, ибо с малолетства разделял пишущие и читающие транзакции. Лично мне У меня это тоже две разные тр-ции. Но только для того, чтобы дать им (возможно) разный набор параметров, а не для обхода проблемы закрытия датасетов. У меня этой проблемы вообще никогда не было. Основное чтение в единой транзакции по умолчанию r_c read, открывающейся на запуске приложения и закрывающейся на выгрузке, запись в коротких по месту снапшотах, с прдварительным рефрешем в них именно модифицируемых данных, если нужно. И фсё. текущее поведение внучков Грегори представляется более логичным и простым в использовании чорным ящиком, нежели борьба с недофетченными курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, отсутствием конфликтов модификации там, где они должны быть. Может, конечно, дело привычки... Поведение _может_ быть настраиваемым, но не _должно_ быть железобетонно- непробиваемым в стиле : "ты туда не ходи, ты сюда ходи... и только сюда" См. выше про молоток и гвоздодёр :) Я, с точки зрения пользователя компонент, не вижу ничего логичного и простого в закрытии всех датасетов по окончании тр-ции. Наооброт - это приводит в недоумение и заставляет _бороться_ с компонентами\сервером вместо решения моих собственных прикладных задач. Не вижу в упор борьбы, если разделять транзакции. И Серж в плюсах это сделал, и Алекс для нас в IBX, причём ещё более радикально, можем на каждый ...SQL отдельную закатать. А раньше мы просто не пользовались технологией Edit-Post, а выполняли модификации автономными запросами. Да и сейчас преимущественно так. -- Regards. Ded.
Re: Немного флейма. Транзакции
"Ded" ... Vlad Khorsun wrote: Может у мну (с) крынка резиновая, но никогда на это не напарывался. Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ? Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко, но иногда бывает и такое). Десятки тысяч не проблема. У меня в филиальской briefcase справочной подсистеме десятками и тягается. С тех пор, как наладил репликацию изменией в базовых справочниках и сборку визуализации на месте из засасываемых оперативных числовых данных и названий в локальной базе, вполне шустренько так летает. А вот спервоначалу, когда отправлял туда резалтсет джойна из центра, в какой-нить Тюмени на модеме минут 40 могло грузиться. То есть, к работе с кеширующими фулл фетч датасетами в общем случае надо технологически подходить не как к клиент-серверу. А это не всегда хорошо. Про работу с миллионными архивами, которые в клиент-сервере до конца вообще практически никогда не дофетчиваются, я уж молчу. Я всегда работаю только через процедуры и всегда только с отфетченным набором данных. Никогда не было необходимости работать с недофетченными данными. Да, забыл упомянуть, - это всё двузвёнка, т.е. никаких брифкейсов\ промкжуточных уровней у меня нет. Так штааа - смотрю на всё со своей колокольни (как, впрочем, и все остальные :) И никаких специальных приседаний с IBX/FIBPlus для этого не надо, технология на это и заточена. Наоборот, надо приседать, когда нужны отступления от этой технологии. Мы с тобой приседаем при помощи CDS, а Серж строит настраиваемые гибриды с локальными сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и гвоздодёр отдельно и хвататься за то, что нужно в конкретный момент. Конечно. Но, согласись, я _сам_ должен выбирать чем гвозди заколачивать, а чем - выдирать. У меня это тоже две разные тр-ции. Но только для того, чтобы дать им (возможно) разный набор параметров, а не для обхода проблемы закрытия датасетов. У меня этой проблемы вообще никогда не было. А я не про тебя это написал :) В обчем - все позиции всех всем давно известны, копья давно сломаны, говорить тут не о чем :) -- Хорсун Влад
Re: Немного флейма. Транзакции
Vlad Khorsun wrote: В обчем - все позиции всех всем давно известны, копья давно сломаны, говорить тут не о чем :) Ну воооттт... А по314деть? :-( -- Regards. Ded/
Re: Немного флейма. Транзакции
> >В обчем - все позиции всех всем давно известны, копья давно сломаны, > > говорить тут не о чем :) > > Ну воооттт... А по314деть? :-( по314деть? Бл#, я не понимаю, как можно быть модератором такого авторитетного ресурса как RSDN и так тупить!!! Сказать что я расстроен, это бл# вообще ничего не сказать. Коваленко Дмитрий.
Re: Немного флейма. Транзакции
> Бл#, я не понимаю, как можно быть модератором такого авторитетного > ресурса как RSDN и так тупить!!! Бл#. Уверен, он делает класс ради одного объекта с одним методом с единственным return-ом. Потому что процедурное программирование уже не модно, а объектное - не асилил. И обращается к нему через глобальный указатель. А когда MS разродится вещами о которых ему там целых два дня вталкивали, не сумеет увязать "вчера" и "сегодня". Про "завтра", я вообще молчу. Коваленко Дмитрий.
Re: Немного флейма. Транзакции
"Kovalenko Dmitry" ... >В обчем - все позиции всех всем давно известны, копья давно сломаны, > говорить тут не о чем :) Ну воооттт... А по314деть? :-( по314деть? Бл#, я не понимаю, как можно быть модератором такого авторитетного ресурса как RSDN и так тупить!!! В каком месте оно авторитетное ? Уж не в СУБД точно :))) -- Хорсун Влад
Re: Немного флейма. Транзакции
> В каком месте оно авторитетное ? Уж не в СУБД точно :))) Ну ты знаешь, я к RSDN прикипел что называется... Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что вроде ничего. Но за последние два дня - ниже плинтуса. --- Коваленко Дмитрий.
Re: Немного флейма. Транзакции
Kovalenko Dmitry wrote: RSDN Ля, и когда вы всё успеваете, да ещё и работать... -- Regards. Ded.
Re: Немного флейма. Транзакции
> Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что > вроде ничего. Но за последние два дня - ниже плинтуса. Я вот смотрю на ответы Ивана. Там в каждом сообщении слова - напрягаться, сложно, устал, тупо ... Однако,тяжела работа у программиста MSSQL. Изматывает и отупляет :)) Коваленко Дмитрий.
Re: Немного флейма. Транзакции
"Kovalenko Dmitry" ... Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что вроде ничего. Но за последние два дня - ниже плинтуса. Я вот смотрю на ответы Ивана. Там в каждом сообщении слова - напрягаться, сложно, устал, тупо ... Он не понимает, что а) в IB\FB нет implicit тр-ций, т.е. тр-циями управляет _только_ клиент в MSSQL это не так и можно увидеть тысячи строк кода как клиентского, так и серверного (процедуры) без BEGIN TRAN. В процедурах, кстати, управление тр-циями разрешено и обычно там его и делают (если делают) б) пример с фетчем и апдейтом односится тоже к клиенту, т.е. тр-ция 2 (апдейтящая) не вычитаывет данные из БД, а получает их на клиенте - поэтому ей не нужно знать, что там меняла 1-я тр-ция (которая ничё не меняла, а только читала). в) 1-я тр-ция видит изменения 2-ой, т.к. она read-committed, а не по другой причине -- Хорсун Влад
Re: Немного флейма. Транзакции
> >> Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что > >> вроде ничего. Но за последние два дня - ниже плинтуса. > > > Я вот смотрю на ответы Ивана. Там в каждом сообщении слова - > > напрягаться, сложно, устал, тупо ... > > Он не понимает, что Да ему просто нечем понимать. Я же говорю мышление настолько плоское, что пытаться ему что-то объяснить - это все равно что разговарить с камнями Тамерлана. Барану объясняют - те на кого он там молится давным давно сформировали спецификацию в которой были недвусмысленно прописаны понятия версионности и нескольких активных множеств. ЗА ДОЛГО ДО ПОЯВЛЕНИЯ MSSQL2005, в котором все это наконец появилось. А до тех пор пока она не появилась - это уже исторические факты - бараны не то что бы не знали про такие вещи, но и говорили - накуй нужно. Однако MS, как только вплотную занялась инструментами для разработчиков, вдруг неожидано решила наоборот. И там же недвусмысленно прописана поддержка нескольких паралелльных активных транзакций. И есть ключик который определяет как будем эти транзакции упаковывать - в одно или разные подключения. Но бл#, этот товарищь уже не в состоянии сделать соответствующие выводы. Он будет тупо смотреть на деревья, не осознавая что стоит перед лесом. Ой, ADO.NET не позволяет сделать несколько независимых транзакций в одном подключений - какой кАшмар! Это ведь не спроста, это же, бл#, самый правильный подход! А если у этих мудил поинтересовать техническими аспектами (типа реализации микрософтовский пула подключений или координатора распределенных транзакций) - кроме мычания и "читайте MSDN" не услышишь. Уверен на все 200% - проверено в попытках узнать "а что же именно делается в момент старта второй отдельной транзакции при незавершенной первой". Кроме бе и ме ничего не добился. Дима Кузьменко - ну как оно, как горох об стену? Коваленко Дмитрий.
Re: Немного флейма. Транзакции
Привет, Kovalenko! Вы пишешь 21 сентября 2007: >> Он не понимает, что KD> Да ему просто нечем понимать. Я же говорю мышление настолько плоское, KD> что пытаться ему что-то объяснить - это все равно что разговарить с KD> камнями Тамерлана. Моё opinion: да ну его в Ж ! (в хорошем смысле) -- With best regards, Alex Cherednichenko.
Re: Немного флейма. Транзакции
Hello, Ded! You wrote on Thu, 20 Sep 2007 18:06:35 +0400: >> RSDN D> Ля, и когда вы всё успеваете, да ещё и работать... "Если пьянка мешает работе - ну её на куй, такую работу!". -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: Немного флейма. Транзакции
Hello, Dmitry! Kovalenko Dmitry wrote: Дима Кузьменко - ну как оно, как горох об стену? Да как обычно. вместо ответа на вопрос начинают какую-то херь про "мы же можем исказить ACID если будем перебрасывать данные между этими транзакциями в приложении!" и прочую муйню. т.е. тут же начинают выдумывать какие-то несусветные ситуации, и стонать о том как это плохо. Это в лучшем случае. В худшем случае все свелось к "тупые ФБ-шники", "это плохо", "это неправильно" и т.д. причем, одни ортодоксы. хоть бы одна падла заявила - ух ты, мне же лишнее соединение не придется открывать! Тут же начинается про "пул соединений" толковище. при чем тут вообще пул, непонятно. Ну а про "вопросы БД не относятся к UI" - я вообще молчу. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Немного флейма. Транзакции
Hello, Alex! Alex Cherednichenko wrote: KD> Да ему просто нечем понимать. Я же говорю мышление настолько плоское, KD> что пытаться ему что-то объяснить - это все равно что разговарить с KD> камнями Тамерлана. Моё opinion: да ну его в Ж ! (в хорошем смысле) да, даже позлобствовать от души не получается. все серое и унылое. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Немного флейма. Транзакции
> Kovalenko Dmitry wrote: > > Дима Кузьменко - ну как оно, как горох об стену? > > Да как обычно. вместо ответа на вопрос начинают > какую-то херь про "мы же можем исказить ACID > если будем перебрасывать данные между этими > транзакциями в приложении!" и прочую муйню. "Я знаю Java, UNIX, Oracle и много других умных слов !" :super: Думаешь так оно и есть? Коваленко Дмитрий.
Re: Немного флейма. Транзакции
> Большинство я так понял сидит в двух звеной архитектуре и самой точно > характеристикой я выбрал бы "У меня на каждой форме своя транзакция" У меня на формах вообще транзакций нет :) > Тотже TClientDataSet тоже упоминался в этой ветке, а никто не думал > зачем его борланд придумал? Я например не знаю - накуя он его придумал. Догадываюсь, но точно не знаю, потому что не юзал ниразу. > А кроме 2-х звеных приложений есть другие архитектуры. > Раскажите мне применение даной возможности в веб приложении? > а в трехвеном приложении? Я кроме лога и фонового опроса (вместо эвентов, к которым я охладел, а второе дыхание чегото не приходит) придумать не могу. > Попарившись с БДЕ мы на очень многое заложились. Я BDE использовал только когда был совсем зеленный. В период испуганного программирования. Короче, Макс. Я убил вагон времени объясняя товарищами - сервер не навязывает вообще ничего. Широкий простор компонент доступа на любой вкус и цвет - тоже. Навязывают люди типа вот этих вот самих товарищей. И объясняя, что не надо, бл#, отвечать за всех и обвинять всех тоже - потому что это реально тупо. Но как об стену горох. А, тут еще дебильные заявления - зачем что то делать когда есть "экспрессы". А когда они появились-то, эти экспрессы? А "благодаря" чему они появились? А какие засады у этих экспрессов? Это, бл#, типа к разговору отношения не имеет. И так далее и тому подобное. Коваленко Дмитрий.
Re: Немного флейма. Транзакции
Hello, Max! Max Rezanov wrote: Большинство я так понял сидит в двух звеной архитектуре и самой точно характеристикой я выбрал бы "У меня на каждой форме своя транзакция" или у меня в программе 2 транзакции одна читающая на всю жизнь и длиная, а одна(N) коротких пишущих. Вам дали такую возможность и вы ее на всю используете и тоже не хотите видеть остального. Тотже TClientDataSet тоже упоминался в этой ветке, а никто не думал зачем его борланд придумал? чтобы сделать briefcase-model, или stateless-обработку, если угодно. А кроме 2-х звеных приложений есть другие архитектуры. Раскажите мне применение даной возможности в веб приложении? а в трехвеном приложении? Создать синглетон с подключением и забирать с него транзакции? мне не кажеться это хорошей мыслью :(. где-то в 1997-1998 году я писал свой пулер коннектов на дельфях, для IB. В нем было: 1. использование отдельных коннектов для долгоиграющих запросов 2. использование одного коннекта для коротких запросов в случае 2 как раз использовались одновременные транзакции, с целью минимизировать рост количества необходимых соединений при увеличении нагрузки. Реально на производительность этот вариант не проверялся. Но архитектурно он был логически здравым. Да мы сечас сидим на C#, трех звеной архитектуре, ADO.NET и оракле. Я не чуствую себя ущербныи из-за того что у меня одна транзакция на соединение и пул подключений на сервере приложений. И кстати вопросы так никто про ущербность не говорит. в Java вообще все иначе, там, если не ошибаюсь, можно организовать пул транзакций :-) Возможно к вам не приходят с предложениями "А у MS откаты больше сколько времени нада на то чтобы переписать это все на MS?". Но от таких вопросов я, в принципе, уже не думаю о самоубийстве :))). не знаю, какие там на MS откаты, если у MS розничных цен как таковых нет. Есть только оптовые. Соответственно, на рынке к этим ценам прибавляют 3-5%, и получается розничная цена. Конечно можно устроить цену в 2-3 раза больше рыночной с целью отката, но если это не коммерческая контора и если директор сам ничего с отката не получил, то цены ведь известны, их в инете навалом. и любая проверка (не милицейская) типа "а почему вы купили софт именно у этой фирмы" этот откат обнаружит. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
