Здравствуйте, AndrewVK, Вы писали:
IT>>Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.
AVK>Ну тогда и я неверно твои слова истолковал. ИМХО ты плохо выразился.
Возможно. Но скорее всего ты додумал то, что хотел
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
H_D>>>Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
IT>>Что значит залезть внутрь? Речь о хаках или о преднамеренном обходе программистом ограничений модели?
AVK>Речь идет о потенциальной ненадежности выполнения кода на клиенте. Причем необязательно это чей то умысел. Может просто взглюкнуть комп.
Цитирую ещё раз:
Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
Где тут речь о глюках компа.
IT>>Первичная валидация данных, например. Зачем гонять на сервер строчку "bla-bla-bla", если известно, что она должна содержать маску ###-###-####?
AVK>Но при этом проверку обязательно нужно повторить на сервере.
Обязательно. И ещё потом кое-что в БД.
AVK>Вот говорю же я что ты от российских реалий слишком отдалился. Проблема обновления софта по всему миру в тысячах офисов перед большинством российских компаний пока не стоит.
Это плохая отмазка. Типа в нашей деревне это не надо.
IT>>Don Box
AVK>Это тот самый, который хочет коммуникацию между доменами через soap делать?
Тот, который по COM+ лушую книжку написал.
AVK>По словам моего начальника, когда он у вышеупомянутого товарища попытался узнать, а как же все таки быть с транзакциями, он получил ответ что мол вот есть же в индиге ремоутинг, им и пользуйтесь.
Ну раз сказал что круглое, значит надо катить
AVK>Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.
А кто у вас определяет востребованность?
IT>>Хана твоему ООП. Сегодня рулят схемы и контракты
AVK>Пока что только на бумаге.
Скоро будут и в Индиге.
IT>>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят.
AVK>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
Я сказал что-то другое? Вопрос в том, о какмх именно объектах идёт речь. Не надо зацикливаться на своём stateful, состояние и управление им может быть лекго разделено и при этом можно получить массу преимуществ.
IT>>Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества
AVK>Опять ты в крайности ударяешься
Это ты насчёт преимуществ?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Alexey Shirshov, Вы писали:
H_D>>> а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.
AS>>За 2 часа? Ох уж этот юношеский максимализм.
IT>Ну почему же? Вполне возможно. Только он потом ещё двое суток это отлаживать будет
А вот щаз обижусь... :cry: между прочем, Б+дерево я НАПИСАЛ за примерно полчаса... потом примерно час отладки + еще полчаса на доводку...
когда я говорю "Написать за два часа" — это значит написать и отладить...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.
IT>>А ты можешь провести чёткую грань?
AVK>Между бизнес-логикой и кодом управления процессом? Могу.
И у тебя всегда управление процессом покрывает все мыслемые нужды бизнес-логики?
IT>>Я тебе предлагаю не изобретать велосипеды.
AVK>А где я такое предлагал? Вот ваша эмуляция состояний при помощи отдельной БД это точно велосипед. И ваши гуиды вместо нормальных транзакций тоже велосипед.
Возможно, но мы не делаем таинственное выражение лица, когда говорим о наших велосипедах. К тому же ты опять как всегда сам не предложил никакого решения. Так что наше решение чемпион, т.к. оно пришло к финишу первым
AVK>И это неверно. Намеки это у ГВ, а я ни про что не намекал. Я сразу же специально написал — никакой конкретики, одна философия.
Тогда нам тяжело будет беседовать. Мне всегда было интересно знать физику процесса, а не рассказы о том, что она есть.
AVK>Подожди, ты чего то не понял. В пределах транзакции нажатие Save не в корневом контексте не должно приводить к появлению чего то вне транзакции. Это требование ТЗ, обсуждать это бессмысленно. Если оно появилось в системе значит транзакция завершена и говорить вобще не о чем.
Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?
IT>>О том, к чему может привести такая "оптимизация", дети BL-девелоперов проходят в детском саде.
AVK>Это уже не оптимизация, это транзакционность и эти самые дети должны понимать что такое транзакция.
Сдаётся мне ты что-то путаешь в терминологии или слишком путано объясняешь. Пример приводить ты как всегда не будешь.
IT>> И подобные вещи корректировались прямо на месте у заказчика без всякой перекомпиляции бизнес логики. А уж при уровне нынешних технологий, я вообще не понимаю о чём идёт речь.
AVK>Вот о том и речь что не понимаешь.
Я сомневаюсь, что тебя вообще кто-то понимает до конца Кроме Влада конечно
AVK>Фишка не в правке чего то вами без перекомпиляции, фишка в возможности глубокой правки системы самим заказчиком вплоть до добавления своих документов, OLTP регистров и прочая. МС вот грозится выпустить на российский рынок MBF и выгнать с него 1С и всех остальных, но это будет относительно нескоро. А пока же никаких подходящих западных решений для малого и среднего бизнеса нет.
И именно это ты называешь своим сервером приложений? Т.е. MS задавит 1C сервером приложений
IT>>Врад ли поможет.
AVK>Ну ты напиши, а потом обсудим, помогло или нет
Дашь референс?
IT>>А ты ничего не пишешь когда тебе нужна новая бизнеслогика?
AVK>В ядре то? Нет конечно. Я (ну не я конечно) пишу исключительно бизнес-логику. Уж точно не пишу каждый раз механику отката, как здесь предлагается.
Мы кажется говорили о производительности и масштабируемости и о том, что в архитектуру нужно закладвать возможность расширяемости. Так вот, это самое простое и эффективное расширяемое решение.
AVK>>>Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?
IT>>Она у меня уже есть по умолчанию. Называется веб-сервисы
AVK>Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем
Я ими связывал .NET и Java. Особых проблем у меня на стороне .NET не было
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
AVK>>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес. S>Хм. горячие парни. Я как-то полагал, что страшное слово stateless относится именно к модели сервера приложений, в которой он отказывается от хранения состояния. При этом он полностью полагается на DBMS (ну, или в более широком смысле слова — на произвольный нижележащий уровень) в том, что касается состояния системы. Надо отметить, что совсем stateless системы — это не более чем игрушка для ума, набор процедурной логики. Складывалка 2+2 — один из примеров. Все интересные сиситемы помимо поведения должны поддерживать еще и состояние. Но это никак не противоречит выбору stateless модели для одного из уровней системы, пока нижние уровни несут на себе этот state.
И уж тем более не противоречит, если тебе нужно продать некий конкретный SQL-сервер вместе с некой конкретной коммуникационной средой.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Alexey Shirshov, Вы писали:
AVK>>Так с лайком и у sql-сервера не все шоколадно AS>А как ты его в своем коде будешь эмулировать? Только не говори, что регулярными выражениями.
Хм... а передать SQL-серверу задачи поиска уже нельзя?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Merle, Вы писали:
TK>>>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти? Tom>>А что это трудно сделать? Вроде как нет M>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
Да, это не совсем полновесный durability, конечно. Откладывать запись можно, как минимум, обеспечивая надёжность питания системы. Но если эта "дырка" прикрыта, то никаких принципиальных препятствий для обеспечения durability, вобщем-то, нет... за исключением возможной ненадёжности и нестабильности модулей памяти App-сервера.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
AVK>>Ну тогда и я неверно твои слова истолковал. ИМХО ты плохо выразился.
IT>Возможно. Но скорее всего ты додумал то, что хотел
То что помимо меня точно так же додумал и Синклер наводит на размышления, не находишь?
Здравствуйте, IT, Вы писали:
AVK>>Но при этом проверку обязательно нужно повторить на сервере.
IT>Обязательно. И ещё потом кое-что в БД.
О, уже кое что, а не все. Прогресс
AVK>>Вот говорю же я что ты от российских реалий слишком отдалился. Проблема обновления софта по всему миру в тысячах офисов перед большинством российских компаний пока не стоит.
IT>Это плохая отмазка. Типа в нашей деревне это не надо.
Ну как бы тебе сказать повежливее. Отмазка может и плохая, но если я буду заниматься решением несуществующих проблем меня просто не поймут.
AVK>>Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.
IT>А кто у вас определяет востребованность?
Заказчик, разумеется. Конкретно для меня куча народа, ответственная за стратегию дальнейшего развития фирмы в целом и конкретного проекта в частности.
IT>>>Хана твоему ООП. Сегодня рулят схемы и контракты
AVK>>Пока что только на бумаге.
IT>Скоро будут и в Индиге.
В индиге много чего будет. Вон веб-сервисы с самого первого фреймворка есть, только рулежа что то не особенно заметно, по крайней мере в России. Один DigiDes чего то там дергался, но выхлоп совсем бледный какой то.
IT>>>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят.
AVK>>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
IT>Я сказал что-то другое?
Ну так перечитай себя. У тебя под стейтлес явно подразумевается что то куда более хитрое. Ну типа есть кошерный стейтлес и некошерный стейтлес (не по Боксу)
IT> Вопрос в том, о какмх именно объектах идёт речь. Не надо зацикливаться на своём stateful, состояние и управление им может быть лекго разделено и при этом можно получить массу преимуществ.
Да, вот как раз меня и надо обвинять в зацикливании на какой то модели
Я говорю что нужно выбирать модель по задаче, от тебя в ответ — конечно же надо, но стейтлес все равно лучше . Так кто из нас зацикливается?
IT>>>Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества
AVK>>Опять ты в крайности ударяешься
IT>Это ты насчёт преимуществ?
Это насчет никаких недостатков. Недостатки есть у обоих моделей и глупо их игнорировать.
Здравствуйте, IT, Вы писали:
IT>>>Я о прерогативах ничего не говорил.
AVK>>То есть речь уже не о stateless/stateful? Ну тогда я пас.
IT>Не надо выворачивать. Я ничего не говорил о наличии/отсутствии объектных запросов в стайтлес модели.
А зачем тогда вобще их обсуждать, выставляя как преимущество стейтлес? Если вы о стейтлес то не надо вобще про это упоминать. Если же нет — так и скажи, я не буду встревать.
AVK>>Это обобщение неверно, поскольку ты учитываешь только время доступа к кешу и не учитываешь коэффициент попадания, который с точностью до наоборот — чем ближе к клиенту тем хуже. Итого суммарная эффективность кеша зависит от обоих показателей. И где у итоговой функции максимум я вот так сказать не берусь.
IT>Если я вынесу справочники на клиента, то попадание всегда будет 100%.
Но на выносе всех справочников на клиента ты просадишь производительность еще как. Эффективность кеша складывается не только из доступа к нему, но и из эффективности его заполнения.
IT>Что здесь не так? К тому же чем ближе к клиенту, тем уже более обработаны данные. Или тебе еще раз привести пример с браузером?
А чем дальше от клиента тем больше и эффективнее может заполняться кеш. Вобщем не надо обобщать
Здравствуйте, IT, Вы писали:
AVK>>Между бизнес-логикой и кодом управления процессом? Могу.
IT>И у тебя всегда управление процессом покрывает все мыслемые нужды бизнес-логики?
Нет, идеального в природе ничего нет, но я стремлюсь к масимально возможному покрытию.
AVK>>А где я такое предлагал? Вот ваша эмуляция состояний при помощи отдельной БД это точно велосипед. И ваши гуиды вместо нормальных транзакций тоже велосипед.
IT>Возможно, но мы не делаем таинственное выражение лица, когда говорим о наших велосипедах.
Я тоже не делаю. Вобще тебе не кажется что подобные аргументы к технической стороне вопроса отношения не имеют, а следовательно не стоит их в техническом споре применять, ибо очень напоминает демагогию.
IT>Тогда нам тяжело будет беседовать. Мне всегда было интересно знать физику процесса, а не рассказы о том, что она есть.
Ну я вроде как и не тебе отвечал, а немного другому IT. Если хочешь услышать что то конкретное от меня — задай вопрос отдельно.
IT>Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?
Нет конечно, с чего ты взял?
IT>Сдаётся мне ты что-то путаешь в терминологии или слишком путано объясняешь. Пример приводить ты как всегда не будешь.
Не буду
AVK>>Ну ты напиши, а потом обсудим, помогло или нет
IT>Дашь референс?
А он что, публично недоступен? stevesw@microsoft.com
AVK>>Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем
IT>Я ими связывал .NET и Java. Особых проблем у меня на стороне .NET не было
Здравствуйте, IT, Вы писали:
AVK>>stateless object объект, не меняющий своего состояния в процессе исполнения AVK>>stateful object объект, кумулятивно изменяющий параметры своего состояния в процессе исполнения по вызовам клиентов
IT>Что такое stateless и stateful мы и без тебя знаем. Ты нам растолкуй, что ты понимаешь под термином 'состояние'. А то пока я вижу, что ты меняешь его трактовку в зависимости от контекста.
Здравствуйте, AndrewVK, Вы писали:
AVK>Но на выносе всех справочников на клиента ты просадишь производительность еще как. Эффективность кеша складывается не только из доступа к нему, но и из эффективности его заполнения.
А вот это — непонятно. Все зависит от того, насколько часто апдейтится справочник. План счетов, например, делает это крайне редко, и cache miss будет происходить раз полгода. Самое главное — обеспечить нормальный механизм проверки когерентности, при котором кэш действительно даст существенный выигрышь. HTTP кэширование живет (грубо говоря) в предположении, что запрос head стоит заметно меньше, чем get. Для супермаленьких страничек (типа неотформатированный термометр в дальнем офисе) никаких преимуществ в случае cache hit нет. Судя по всему, ты говоришь именно об этом.
Тем не менее client-side joins — это вполне играющая технология. Я вообще читал как-то статью про маньяков, которые сделали predicate-based caching с уведомлениями. Правда, там не упоминалось никакого прикладного использования — академики, чистый prove of concept Зато звучит круто. А то, мол, в типичной конторе сервак отдичается только тем, что у него стоит гиг памяти, а не 256, и винт SCSI, а не IDE. А все клиенты тщетно пытаются загрузить свой проц при помощи show transparent window contents while dragging и фонового воспроизведения mpeg4, пока наконец срефрешится список документов
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да, это не совсем полновесный durability, конечно. Откладывать запись можно, как минимум, обеспечивая надёжность питания системы. Но если эта "дырка" прикрыта, то никаких принципиальных препятствий для обеспечения durability, вобщем-то, нет... за исключением возможной ненадёжности и нестабильности модулей памяти App-сервера.
Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.
И дело даже не только в надежности питания. Может существовать еще 33 причины, по которым твоя зафиксированная в памяти транзакция до диска просто не доедет, начиная от небольших ошибок в App-коде, которые вылезут на такой вот транзакции спустя полгода после ввода системы в эксплуатацию у заказчика, и заканчивая пролетом через сервер космических частиц.
Не говоря уже о том, что когда на сервере-таки питание кончится, то уборщице, с ее шваброй, конечно, по голове дадут, но тебе тоже будет больно и обидно, а отмазки типа "ну надо было питание обеспечивать" как правило не канают.
Не даром, на серьезных базах все хитрые режимы кэш-контроллеров отключают, чтобы если база отрапортовала, что транзакция зафиксирована, значит она действительно зафиксирована, а не торчит в памяти кэш-контроллера.
При твоем же подходе выигрыш копеечный, а проблем на свою голову огрести можно очень много.
Здравствуйте, Merle, Вы писали:
M>Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.
Не, тут ты уже передергиваешь. При такой постановке его вобще не существует. Например тот же MSSQL буковку D обеспечивает гарантированно только при отсутствии аппаратного кеша диска. Если же такой наличествует то нет никакой гарантии что при его взглюкивании база не осыпется.
M>И дело даже не только в надежности питания. Может существовать еще 33 причины, по которым твоя зафиксированная в памяти транзакция до диска просто не доедет, начиная от небольших ошибок в App-коде, которые вылезут на такой вот транзакции спустя полгода после ввода системы в эксплуатацию у заказчика, и заканчивая пролетом через сервер космических частиц.
Но точно так же могут вылезти ошибки в firmware винта, что бывало уже не раз. Нет никакой абсолютной durability, есть только верояность приключения неприятностей, большая или меньшая.
M>Не говоря уже о том, что когда на сервере-таки питание кончится, то уборщице, с ее шваброй, конечно, по голове дадут, но тебе тоже будет больно и обидно, а отмазки типа "ну надо было питание обеспечивать" как правило не канают.
Ну точно так же та же уборщица может мокрой тряпкой по серваку пройтись и пожечь винты. Ей конечно, по голове дадут, но тебе тоже будет больно и обидно, а отмазки типа "ну надо было отсутсвие уборщицеподобных личностей в серверной обеспечивать" как правило не канают.
Здравствуйте, Sinclair, Вы писали:
S>Все зависит от того, насколько часто апдейтится справочник.
Конечно.
S>План счетов, например, делает это крайне редко, и cache miss будет происходить раз полгода.
А другой справочник обновляется частенько и постоянное пересбрасывание кеша на клиенте может серьезно снизить эффективность кеша у клиента. Что собственно и требовалось доказать.
S>Тем не менее client-side joins — это вполне играющая технология.
Да я не спорю. Я против обобщения что клиентский кеш всегда лучше.
Здравствуйте, AndrewVK, Вы писали: AVK>Да я не спорю. Я против обобщения что клиентский кеш всегда лучше.
Не, поинт IT был в том, что кэш на стороне сервера помогает слабо
В случае частых апдейтов кэш и на серверной стороне не спасет. Хотя... Если это кэш применения XPATH к XML, то и на серверной стороне он подымет производительность в разы...
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
Кроме Влада конечно 
Мы уже победили, просто это еще не так заметно...
