AVK>Ты чего вобще хочешь?

Если ты еще не в курсе то СОМ+ МС уже вобщем то похоронил

Где MC говорит о том что COM+ похоронил?

Здравствуйте, Tom, Вы писали:

Tom>Где MC говорит о том что COM+ похоронил?

Ну почитай про Индигу. То есть COM+ там конечно присутствует, но исключительно в качестве совместимости, часть служб менеджед и СОМ+ с ними будет общаться через интероп.

AVK>Ну почитай про Индигу. То есть COM+ там конечно присутствует, но исключительно в качестве совместимости, часть служб менеджед и СОМ+ с ними будет общаться через интероп.

Документации пока очень мало но насколько я вижу кроме транзакций которые и так работают великолепно без деплоймента в COM+ там ничего революционного. Где там как минимум: Objects Pooling, JIT, Synchronization Domains ? В основном все навароты основанны на передаче сообщений разными способами и их интеграции.

Здравствуйте, Tom, Вы писали:

Tom>Документации пока очень мало но насколько я вижу кроме транзакций которые и так работают великолепно без деплоймента в COM+ там ничего революционного. Где там как минимум: Objects Pooling, JIT, Synchronization Domains ? В основном все навароты основанны на передаче сообщений разными способами и их интеграции.

Там есть глава по поводу использования WinFX в unmanaged приложениях.

Здравствуйте, Tom, Вы писали:

IT>>Сделать можно разными способами, но курсоры как и вообще базы данных имеет к этому весьма опосредованное отношение.

Tom>Гы
Tom>У нас это реализовали именно на основе OLE DB и Dynamic курсоров,

Т.е. ты открываешь соединение к базе, открываешь курсор к таблице и ждёшь когда тебе придёт уведомление об изменении? Оригинально! А вы гвозди мискроскопом не пробовали заколачивать? Сколько интересно пользователей будет у вашей системы, 2, 5? И потом, кто тебе сказал, что в OLE DB используется не пуллинг

Tom>а вот Ты решения на основе stateless так и не предложил.

Во-первых, я не телепат, а ты мне не дал исходных данных. Во-вторых, почему решение должно быть обязательно stateless?

Здравствуйте, Tom, Вы писали:

Tom>>>А может ты путаешь stateless и persistent connection less?
IT>>Это термин совсем из другой оперы, к нашему разговору отношения не имеет
Tom>Давай так: stateless — это когда состояния НЕТ, а не когда состояние есть но хранится не понятно где

Состояние чего?

Tom>ЗЫ: Надо определятся с терминологией, а то спорит народ не понятно о чём.

Да с ней уже давно всё давно определено и не нами. Но похоже ты пытаешься внести новизну в эти определения

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Tom, Вы писали:

IT>>>Сделать можно разными способами, но курсоры как и вообще базы данных имеет к этому весьма опосредованное отношение.

Tom>>Гы
Tom>>У нас это реализовали именно на основе OLE DB и Dynamic курсоров,

IT> Т.е. ты открываешь соединение к базе, открываешь курсор к таблице и ждёшь когда тебе придёт уведомление об изменении? Оригинально! А вы гвозди мискроскопом не пробовали заколачивать?
Нет. Написали свой ole db provider и real time server к нему

IT>Сколько интересно пользователей будет у вашей системы, 2, 5? И потом, кто тебе сказал, что в OLE DB используется не пуллинг
Не знаем. Банки эту информацию не выдают. Просто покупают не ограниченную лицензию.

Tom>>а вот Ты решения на основе stateless так и не предложил.
IT>Во-первых, я не телепат, а ты мне не дал исходных данных. Во-вторых, почему решение должно быть обязательно stateless?
Непонял. Это как же нам без stateless Кто то ж за него грудью стоит

Здравствуйте, Tom, Вы писали:

IT>> Т.е. ты открываешь соединение к базе, открываешь курсор к таблице и ждёшь когда тебе придёт уведомление об изменении? Оригинально! А вы гвозди мискроскопом не пробовали заколачивать?
Tom>Нет. Написали свой ole db provider и real time server к нему

Вот этого я больше всего и боялся. А сервер базы данных вы свой не написали?

IT>>Сколько интересно пользователей будет у вашей системы, 2, 5? И потом, кто тебе сказал, что в OLE DB используется не пуллинг
Tom>Не знаем. Банки эту информацию не выдают. Просто покупают не ограниченную лицензию.

Ничего выдадут, когда SQL сервер начнёт тормозить из-за нехватки ресурсов.

IT>>Во-первых, я не телепат, а ты мне не дал исходных данных. Во-вторых, почему решение должно быть обязательно stateless?
Tom>Непонял. Это как же нам без stateless Кто то ж за него грудью стоит

Видимо ты давно потерял нить разговора. Попробуй прочитай всю тему с самого начала

Здравствуйте, Tom, Вы писали:

Tom>>>А может ты путаешь stateless и persistent connection less?
IT>>Это термин совсем из другой оперы, к нашему разговору отношения не имеет
Tom>Давай так: stateless — это когда состояния НЕТ, а не когда состояние есть но хранится не понятно где
Не, противовоставление stateless-stateful относится только к промежуточному слою. Если уж у тебя есть объекты, то у них состояние есть есть всегда, но не всегда это состояние хранится в промежуточном слое. Только и всего.

Tom>>>Слово то простое. stateless и говорит оно что state less а не state у нас в базе данных и мы тут его ручками круто эмулируем
IT>>Только не надо сочинять собственную интерпретацию устоявшейся терминологии. Stateless — это stateless, т.е. без состояния. А после 'state less' напрашивается как минимум 'than'
Tom>ты это. не отмазывайся
Tom>ЗЫ: Надо определятся с терминологией, а то спорит народ не понятно о чём.
Почему? Всё понятно в общем. Одни уверяют, что используя stateless (см. примечание выше) можно эмулировать stateful (и они, ИМХО, совершенно правы), а другие давят на то, что это приведёт к снижению производительности и к неудобству программирования (ИМХО, тоже совсем небезосновательно). Ну а дальше всё как полагается в порядочном споре — сарказм, язвительности, тень на всех плетнях и т.п.

Здравствуйте, AndrewVK, Вы писали:

IT>>Что такое stateless и stateful мы и без тебя знаем. Ты нам растолкуй, что ты понимаешь под термином 'состояние'. А то пока я вижу, что ты меняешь его трактовку в зависимости от контекста.

AVK>Набор данных, семантически связанных с объектом.

угу, любые данные, имеющие отношение к объекту.

Здравствуйте, IT, Вы писали:

IT>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.

Или использовать некий стандартный механизм хранения данных серверного объекта на клиенте. А если этот механизм еще будет поддерживать бининг в полном объеме — то это в разы все упрощает.

IT>Ну как же? Твой объект живёт на сервере и у меня имеется только ссылка на него. Занимать такой ерундой как запоминать какие его свойства я уже прочитал, а какие нет, я не собираюсь.

Хм, я именно это и делаю в своей системе. Вернее, система сама это делает. Это особенно актуально, если нам нужно не просто значение некоего св-ва (строка или число), а список связанных объектов.

IT>Для таких задач лучше подходят всевозможные системы data/business flow, которые как раз и обеспечивают то, что ты называешь длинными транзакциями. TK уже предлагал для этого задействовать BizTalk, в принципе я с ним согласен. Подобные задачи представляются достаточно простыми при наличии соответствующего софта и осилисть их может человек, являющийся специалистом в предметной области. Высококвалифицированным программистом для этого быть не надо. Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

Можно обойтись и без "длинных транзакций". Если мы имеем на серваке StateFull, и эти незакоммиченные данные доступны другим сессиям по read-only, то можно добиться интересных эффектов.

Пример из жизни:
— десятки девочек набивают накладные
— накладные состоят в среднем из 100-300 строк (оптовая торговля бытовой химией), т.е. процедура набивки одной накладной довольно длинная
— в системах типа 1С постоянно случаются накладки, когда несколько девочек пытаются одновременно продать остатки одной и той же позиции товара, ибо на момент набивки им всем система показывает наличие товара

В моей системе сервер приложений разруливал подобную ситуацию. Т.е. используя statefull модель накладных, он позволял оперировать не только остатками товаров на складах по результатам транзакций, но и мгновенными остатками, с учетом текущих редактируемых данных коллеги за соседним столом.

Подобная задача может быть решена и через stateless, но весьма ненадежно. (Именно таким был первый вариант решения задачи). Т.е. суть решения состояла в организации доп. состояния документа — черновик, и каждая строчка накладной отправлялась на сервак. Был общий регистр "набиваемых" данных. Вроде все работало, до тех пор, пока девочки корректно выходили из клиентских программ. Если же из программы вышли неккоректно в момент набивки накладных, то вся логика просто слетала. Приходилось наверчивать доп. операции, типа — сброс регистров набиваемых данных, эту операцию нужно было выполнять в тот момент, когда никто не редактировал накладные... И вся эта пляска вокруг однойтолько бизнес-задачи. В общем, наглядная демонстрация процедуры удаления гланд при неправильной начальной предпосылке расположения оных.

Статефулл решил все проблемы сразу, просто и элегантно.

IT>Чудес не бывает. Снимая нагрузку с сервера БД ты её просто переносишь на сервер приложений, вот и всё. Насчёт более оптимальных запросов, обеспечиваемых сервером приложений. Это справедливо только для примитивных запросов, и то же самое можно закешировать и в stateless. Для сложных запросов на практике это не реально. Пять строчек на SQL с парой вложенных джоинов обычно выливаются в десятки, если не в сотни строк на C++/C#/whatever, реализующих поиск, фильтрацию и сортировку в объектной модели и отнюдь не отличаются быстродействием доморощенных алгоритмов.

Правильная тема для обсуждения. Свой енжин пишу как раз и для подобных задач. Дело в том, что мы, разработчики, обычно точно знаем характер взаимодействия со своими данными, а сервак SQL — нет. Справочники я обычно смело кеширую на апп-серваке, и уверяю, эти join-ы работают гораздо быстрее, чем на стороне SQL. Если решать задачу не каждый раз заново, а именно решить единожды — то все получается ok.


IT>Я пока что-то не пойму, откуда такая уверенность что в stateless над БД так и наровят постоянно надругаться. Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.

IT>>>Правильное кеширование в стэйтлес позволяет добиться аналогичных результатов.

AVK>>Только достигается оно куда большей кровью при помощи эмуляции тех же самых стейтов, о чем я ранее и писал.

IT>При помощи кеширования.

Кеширование бывает не только на апп-серваке, но и на клиенте. В статефул-модели мы можем поручить нашему движку самому разбираться, какие данные надо подгрузить на клиента, а какие не надо. То же самое при отправке их обратно на сервак. В случае медленного коннекта клиента — это сильное подспорье. Даже в случае быстрого, но тарифицируемого за каждый MB трафика — тоже.

IT>Не так. Ты путаешь понятия cache и storage. Да, они оба как бы типа хранят состояние. Но наличие данных в первом совсем не обязательно и предназначено только для одной функции — снятие нагрузки с базы данных постредством реиспользования ранее произведённых запросов. Для второго — наличие данных это часть логики. Например, через кэш можно получить два разных экземпляра одной и той же записи БД. Для stateless в этом нет ничего страшного. Но, если твоё хранилище в stateful вернёт два экземпляра одного и того же объкта, то это уже не stateful, а либо глючный stateful, либо stateless

Правильное замечание. Для этих целей у нас отделены Entity от EntityView. Entity может быть только в 1-м экземпляре в кеше или не быть вовсе. Экземпляров EntityView может быть много. Всю потоко- и транзакционную безопасность они разруливают м/у собой сами.

IT>Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.

Конечно StateFull. Ибо любой statefull легко приводим к stateless. У нас в системе есть несколько сущностей, которые ведут себя как stateless, потому как на каждый чих скидывают свое сосстояние в БД (и в кеш соответственно). Владение разными экземплярами EntityView одним экземпляром Entity автоматичеки синхронизирует изменения в соседних клиентских сессиях.

IT>>>То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.

Всю модель никто и не ложит в память. Обычно настраивают политику использования кеша для каждой сущности. Для справочных данных — это было бы оправданно почти всегда, для остальных — в зависимости от задачи.

AVK>>Веб-приложения как правило никто и не стремится сделать стейтфул.

IT>Да уже и GUI не очень-то стремяться.

Делать хорошее ГУИ вообще давно не стремятся.

IT>Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы

Скажем прямо — когда как. Стоит захотеть положить на форму полнофункциональный грид — и сразу прощай веб-форма в ГУИ. Да и вообще, при интенсивном взаимодействии на клиенте с этим ГУИ неудобно работать с embedded web-form, гораздо проще оперировать обычным Windows.Forms.

Хотя, в своем редакторе запросов взяли именно WebForm, и прилично натрахались со сложным взаимодействием с ней... И все только из-за мощных ср-в управления layout-ом.

IT>>>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.

В разы обычно уменьшается и трафик и время отклика. При централизованном подходе к синхронизации, и применении кеша не только на стороне апп-сервера, но и при агрессивном кешировании на клиенте — все начинает работать гораздо быстрее.

IT>Для оптимизации БД существуют соответствующие средства. Для оптимизации твоего сервера приложений, который, между прочим, хорошо знает предметную область, таких средств нет, либо их нужно разрабатывать сомостоятельно.

Обычно нужно разработать небольшое семейство политик кеширования и политик синхронизации, а конкретным прикладным сущностям просто прописывать эти политики. Подобная гибкость и не снилась серверам SQL. Например, после годовой работы с приложением можно скорректировать политику сущностей исходя из реальных объемов и соотношений данных.

IT>Самое фиговое в stateful — это когда понимаешь что чтобы сделать следующий шаг, нужно пройти в два раза больше чем пройдено, что столько усилий потрачено, а результат получился хреновый.

Statefull тут не причем. Такое понимание приходит всегда, когда сложные вещи решаешь каждый раз заново. Автоматизировать надо-ссс..

IT>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.

Все ясно. Вопрос вообще о подходе к написанию многозвенных приложений. С тем, что statefull изначально проще в реализации простых операций, типа: прочитать, изменить, записать, никто и не спорил. Однако очевидно, что с помощью statefull становится сложновато строить приложения, где необходима мгновенная реакция на изменения в системе, вызванные "соседним" пользователем. Применяя stateless вообще сложновато координировать м/у собой действия различных пользователей в системе, если таковая задача вдруг встанет. И этот принцип я бы не стал делить по применимости на Web- или GUI-приложения. On-line GUI клиента к RSDN я бы тоже выполнил в виде stateless модели. Однако WEB-формы выписки накладных из приведенного выше примера — однозначено statefull.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>>>А это уже бабе Мане решать.
ГВ>>>Смешно. Уже вижу бабу Маню с дебуггером в руках. Но я не об этом спрашивал. Хорошо, поставим вопрос по-другому. Что баба Маня сможет сделать? Ну, из каких вариантов будет у неё выбор? И как будет клиент (и/или сервер) обрабатывать выборы бабы Мани?
IT>>Расскажи мне о каких хитрых ситуациях шла речь, я тебе скажу что должна делать баба Маня.

ГВ>Один из документов, откуда вытягиваются данные для этой транзакции, оказался удалён в промежутке между подкачкой его в кэш клиента и завершением транзакции.

ГВ>То есть, имеем следующее:

ГВ>Для ввода и обсчёта документа A используется несколько документов B: b1, b2, b3. Начинаем вводить новый документ a1, для которого подкачиваем на клиента информацию из b1, b2, b3. К моменту нажатия на <Commit> оказывается, что b2 уже успела удалить баба Дуся.

ГВ>Внимание, вопросы: Как поведёт себя система? Что произойдёт на клиенте? Что сможет сделать баба Маня?

В 10-ку. Как только речь заходит об управлении взаимодействием пользователей системы (взаимодействием через результаты операций), так stateless оказывается практически бессильным.

Здравствуйте, TK, Вы писали:

TK>Ну, либо у нас один сервер, либо их несколько (тут конечно надежност и т.п.), но тогда как быть с аргументами о том, что в случае со стайтфул — очень просто организовать кеширование данных (несколько машин, общий кеш в памяти и т.п.)...

Да не бывает полностью statefull-приложений. Система управления предприятием может иметь сервисы внутри апп-сервака, которые представляют из себя stateless. Просто редактирование связанных документов — это именно та область, где очень неплохо работает statefull, и очень сложно добиться адекватного поведения от stateless. Я бы разбил логику сервера приложений на несколько составляющих:
— бизнес-сервисы, т.е. некие статические бизнес-методы или методы статических объектов, которые выполняют операцию за один вызов, тут у всех волей-неволей получается stateless
— поддержка редактирования документов, здесь statefull рулит, т.к. иногда может потребоваться прилично информации для поддержки процесса, и эту гору информации необязательно гонять на клиента.

Соответственно, когда речь заход о масштабируемости, то учитываем свою специфику. Например, сервисная часть легко поддается "тупому" масштабированию. Statefull-часть может работать вообще на отдельном сервере приложений, если очень надо... В принципе, там большая скорость обычно не требуется, ибо люди вносят/изменяют информацию крайне медленно с т.з. выч. систем. А отчетность и аналитика сидит на сервисах, т.е. на других хостах в нашем случае. Если же мощности все-равно не хватает, то я бы разбил бизнес-задачи на несвязанные или слабосвязанные наборы документов, и распределял бы нагрузку именно таким образом — согласно уровню связанности.


ГВ>>Всё зависит от того, что именно и как сопровождается. Stateful-модель никак нас по сути не ограничивает в таком способе освобождения одного из серверов кластера, как перенос контекста пользователя на другой сервер. А это уже не полная и безоговорочная остановка работы системы а просто небольшая заминка.

TK>Перенос контекста пользователя? Это уже достаточно интересная и не тривиальная операция, которая требует отдельной поддержки со стороны app сервера. Какие из них (+ цены) умеют подобное?

Самое интересное, что в statefull серваках обычно есть такое понятие, как сессия, и сессия "знает" обо всех удерживаемых объектах. Достаточно перенести те объекты, которые находятся в промежуточном состоянии, остальные можно "поднять" по месту.

Но и это перегиб, имхо. Лучше не переносить контекст пользователя, а сразу создавать этот контекст на другом серваке.

Здравствуйте, vdimas, Вы писали:

V>В 10-ку. Как только речь заходит об управлении взаимодействием пользователей системы (взаимодействием через результаты операций),

Что это ты вдруг решил реанимировать трупика двух-летней давности?

V>так stateless оказывается практически бессильным.

Да ещё и всякие глупости про stateless говоришь?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, vdimas, Вы писали:

V>>В 10-ку. Как только речь заходит об управлении взаимодействием пользователей системы (взаимодействием через результаты операций),

IT>Что это ты вдруг решил реанимировать трупика двух-летней давности?

А прямо сейчас решаю извечную проблему, какие объекты в системе делать statefull, а какие stateless.

V>>так stateless оказывается практически бессильным.

IT>Да ещё и всякие глупости про stateless говоришь?

Да нет, есть реальные сценарии, согласно которым stateless потребует на порядок больше трафика и чуть больше методов в удаленном объекте, да и кода слишком много получается как на клиенте, так и на сервере...

Здравствуйте, vdimas, Вы писали:

IT>>Да ещё и всякие глупости про stateless говоришь?

V>Да нет, есть реальные сценарии, согласно которым stateless потребует на порядок больше трафика и чуть больше методов в удаленном объекте, да и кода слишком много получается как на клиенте, так и на сервере...

Этого не может быть Насчёт скорости, ты попробуй кеширование поиспользовать, очень сильно помогает

Здравствуйте, IT, Вы писали:

IT>>>Да ещё и всякие глупости про stateless говоришь?
V>>Да нет, есть реальные сценарии, согласно которым stateless потребует на порядок больше трафика и чуть больше методов в удаленном объекте, да и кода слишком много получается как на клиенте, так и на сервере...

IT>Этого не может быть Насчёт скорости, ты попробуй кеширование поиспользовать, очень сильно помогает

Может. Это даже теоретически несложно доказать. Если грубо, то получаем либо перемещение либо complete-state, либо state-delta (разницу между двумя состояниями). В общем — тут уже много было сказано по этому поводу.

Здравствуйте, vdimas, Вы писали:

Пофлудим?

IT>>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.

V>Или использовать некий стандартный механизм хранения данных серверного объекта на клиенте. А если этот механизм еще будет поддерживать бининг в полном объеме — то это в разы все упрощает.

Вопрос не в простоте, вопрос в производительности приложения. Что больше напрягает сервер — один большой запрос или много маленьких?

IT>>Ну как же? Твой объект живёт на сервере и у меня имеется только ссылка на него. Занимать такой ерундой как запоминать какие его свойства я уже прочитал, а какие нет, я не собираюсь.

V>Хм, я именно это и делаю в своей системе. Вернее, система сама это делает.

Да это как бы не проблема, в RFD даже поддержка для этого есть. Но всё равно вопрос, если тебе надо прочитать сначала поле FirstName, а затем LastName, ты два раза к серверу будешь обращаться?

V>Это особенно актуально, если нам нужно не просто значение некоего св-ва (строка или число), а список связанных объектов.

Подгрузка списков это отдельная задача. Обычно достаточно двух типов методов для top-объектво в иерархии: GetSomething и GetSomethingDetails. Первый возвращает единственную запись в которой хранится сам объект, второй ту же запись + все подчинённые объекты, их списки и т.д. Т.е. такой запрос полностью восстанавливает иерархию объекта.

IT>>Для таких задач лучше подходят всевозможные системы data/business flow, которые как раз и обеспечивают то, что ты называешь длинными транзакциями. TK уже предлагал для этого задействовать BizTalk, в принципе я с ним согласен. Подобные задачи представляются достаточно простыми при наличии соответствующего софта и осилисть их может человек, являющийся специалистом в предметной области. Высококвалифицированным программистом для этого быть не надо. Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

V>Можно обойтись и без "длинных транзакций". Если мы имеем на серваке StateFull, и эти незакоммиченные данные доступны другим сессиям по read-only, то можно добиться интересных эффектов.

Ну да. Можно добиться, например, подвисания сервера и, в результате, потери данных.

V>Пример из жизни:
V>- десятки девочек набивают накладные
V>- накладные состоят в среднем из 100-300 строк (оптовая торговля бытовой химией), т.е. процедура набивки одной накладной довольно длинная
V>- в системах типа 1С постоянно случаются накладки, когда несколько девочек пытаются одновременно продать остатки одной и той же позиции товара, ибо на момент набивки им всем система показывает наличие товара

Действительно, такие задачи иногда встречаются в жизни. Но строить на основании этого всю систему как stateful — это нонсенс. Такую задачку надо выделить из общей массы, отвести её в сторонку (можно вместе с девочками) и там решить. Но только не надо обобщать подход к решению подобных задач на всё бизнес приложение в целом (если оно, конечно, не состоит из одной такой задачки).

V>В моей системе сервер приложений разруливал подобную ситуацию. Т.е. используя statefull модель накладных, он позволял оперировать не только остатками товаров на складах по результатам транзакций, но и мгновенными остатками, с учетом текущих редактируемых данных коллеги за соседним столом.

Думаю, что можно было бы отделаться только кешированием твоих мгновенных остатков. Делать для этого statefull модель накладных скорее всего совсем не обязательно.

V>Подобная задача может быть решена и через stateless, но весьма ненадежно.

Не верю По большому счёту stateful от stateless отличается только лишь тем, что state в stateless всегда гарантированно ложится в базу данных, а в statefull не всегда, иногда только в память апп-сервера. Остальное — это приёмы использования кеша и борьбы с ним.

V>(Именно таким был первый вариант решения задачи). Т.е. суть решения состояла в организации доп. состояния документа — черновик, и каждая строчка накладной отправлялась на сервак. Был общий регистр "набиваемых" данных. Вроде все работало, до тех пор, пока девочки корректно выходили из клиентских программ. Если же из программы вышли неккоректно в момент набивки накладных, то вся логика просто слетала. Приходилось наверчивать доп. операции, типа — сброс регистров набиваемых данных, эту операцию нужно было выполнять в тот момент, когда никто не редактировал накладные... И вся эта пляска вокруг однойтолько бизнес-задачи. В общем, наглядная демонстрация процедуры удаления гланд при неправильной начальной предпосылке расположения оных.

И как ты удаляешь эти гланды теперь?

V>Статефулл решил все проблемы сразу, просто и элегантно.

Неужели stateful штрафует девочек за некорректный выход из программы?

V>Правильная тема для обсуждения. Свой енжин пишу как раз и для подобных задач. Дело в том, что мы, разработчики, обычно точно знаем характер взаимодействия со своими данными, а сервак SQL — нет. Справочники я обычно смело кеширую на апп-серваке, и уверяю, эти join-ы работают гораздо быстрее, чем на стороне SQL. Если решать задачу не каждый раз заново, а именно решить единожды — то все получается ok.

Советую пользоваться индекстами
Впрочем, для монстрообразных справочников кеширование здорово помогает. Но, как я уже сказал выше, это с успехом и с теми же проблемами делается как в stateless, так и в stateful. Разницы никакой.

V>Кеширование бывает не только на апп-серваке, но и на клиенте. В статефул-модели мы можем поручить нашему движку самому разбираться, какие данные надо подгрузить на клиента, а какие не надо. То же самое при отправке их обратно на сервак. В случае медленного коннекта клиента — это сильное подспорье. Даже в случае быстрого, но тарифицируемого за каждый MB трафика — тоже.

Могу ещё раз сказать про кешь — в обоих подходах с ним работа практически идентична. За исключением, пожалуй, одной вещи. В stateful кешь легко превращается в storage объектов в памяти, что при всей своей привлекательности несёт в себе массу других проблем.

IT>>Не так. Ты путаешь понятия cache и storage. Да, они оба как бы типа хранят состояние. Но наличие данных в первом совсем не обязательно и предназначено только для одной функции — снятие нагрузки с базы данных постредством реиспользования ранее произведённых запросов. Для второго — наличие данных это часть логики. Например, через кэш можно получить два разных экземпляра одной и той же записи БД. Для stateless в этом нет ничего страшного. Но, если твоё хранилище в stateful вернёт два экземпляра одного и того же объкта, то это уже не stateful, а либо глючный stateful, либо stateless

Ну да, видишь, я об этом ещё два года назад говорил

V>Правильное замечание. Для этих целей у нас отделены Entity от EntityView. Entity может быть только в 1-м экземпляре в кеше или не быть вовсе. Экземпляров EntityView может быть много. Всю потоко- и транзакционную безопасность они разруливают м/у собой сами.

Ok. Пример из жизни. Загружаешь ты, например, накладную. Вместе с ней поднимается и товары. Товаров в базе данных мильёны. Грузить их все в кешь не имеет смысла. А может и имеет для каких-то случаев В любом случае какие-то товары у тебя уже в памяти. Теперь в другой части приложения ты делаешь запрос по какому то критерию для получения списка товаров. В качестве результата приезжает список как закешированных, так и не закешированных товаров. Что ты делаешь в этом случае? Мне правда интересно. Я занималься в своё время такой фигнёй, задача решаемая, но как-то глядя на это всё плакать хочется.

IT>>Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.

V>Конечно StateFull. Ибо любой statefull легко приводим к stateless.

Ты это серьёзно? Может мы используем разные термины? Ты под stateful понимаешь то, что я под statless, а я под stateful, то что ты под stateless? Вот простой вопрос. Как ты превратишь stateful решение в масштабируемое?

V> У нас в системе есть несколько сущностей, которые ведут себя как stateless, потому как на каждый чих скидывают свое сосстояние в БД (и в кеш соответственно). Владение разными экземплярами EntityView одним экземпляром Entity автоматичеки синхронизирует изменения в соседних клиентских сессиях.

Какой же это stateless? Типичный stateful, только с гарантированным сохранением данных в БД.

IT>>>>То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.

V>Всю модель никто и не ложит в память. Обычно настраивают политику использования кеша для каждой сущности. Для справочных данных — это было бы оправданно почти всегда, для остальных — в зависимости от задачи.

Для остальных вообще как правило ничего не имеет смысла кешировать.

IT>>Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы

V>Скажем прямо — когда как. Стоит захотеть положить на форму полнофункциональный грид — и сразу прощай веб-форма в ГУИ. Да и вообще, при интенсивном взаимодействии на клиенте с этим ГУИ неудобно работать с embedded web-form, гораздо проще оперировать обычным Windows.Forms.

Разве? А где ты видел нормальный грид для гуёв? Веб-грид хоть и простенький, но с ним можно практически всё делать. А что нельзя, можно на таблицах. Думаю, кода будет не больше, чем при кастомизации гуёвого грида.

V>Хотя, в своем редакторе запросов взяли именно WebForm, и прилично натрахались со сложным взаимодействием с ней... И все только из-за мощных ср-в управления layout-ом.

Вы наверное стремились всё сделать pixel-perfect?

IT>>>>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.

V>В разы обычно уменьшается и трафик и время отклика. При централизованном подходе к синхронизации, и применении кеша не только на стороне апп-сервера, но и при агрессивном кешировании на клиенте — все начинает работать гораздо быстрее.

Подожди-ка, мы не о кеше опять, а о синхронизации состояний одного и того же объекта на разных серверах.

IT>>Для оптимизации БД существуют соответствующие средства. Для оптимизации твоего сервера приложений, который, между прочим, хорошо знает предметную область, таких средств нет, либо их нужно разрабатывать сомостоятельно.

V>Обычно нужно разработать небольшое семейство политик кеширования и политик синхронизации, а конкретным прикладным сущностям просто прописывать эти политики. Подобная гибкость и не снилась серверам SQL. Например, после годовой работы с приложением можно скорректировать политику сущностей исходя из реальных объемов и соотношений данных.

Ну ты понял... про кеширование

IT>>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.

V>Все ясно. Вопрос вообще о подходе к написанию многозвенных приложений. С тем, что statefull изначально проще в реализации простых операций, типа: прочитать, изменить, записать, никто и не спорил. Однако очевидно, что с помощью statefull становится сложновато строить приложения, где необходима мгновенная реакция на изменения в системе, вызванные "соседним" пользователем. Применяя stateless вообще сложновато координировать м/у собой действия различных пользователей в системе, если таковая задача вдруг встанет. И этот принцип я бы не стал делить по применимости на Web- или GUI-приложения. On-line GUI клиента к RSDN я бы тоже выполнил в виде stateless модели. Однако WEB-формы выписки накладных из приведенного выше примера — однозначено statefull.

Я уже сказал, что такой класс задач гораздо реже встречается в природе чем "простые операции типа: прочитать, изменить, записать". Да и такие задачи можно и нужно раскладывать на простые операции и в результате там от stateful останется один простой список текущих остатков. Ты же, похоже, создав целый фреймворк для твоей задачи, пытаешься не только обобщить это всё на весь stateful, но и убедить всех, что это единственно правильное решение. Это не так. Уверен, что твою задачу можно было бы спокойно решить малой кровью без строительства завода для производства одного гвоздя.

Здравствуйте, IT, Вы писали:

V>>Да нет, есть реальные сценарии, согласно которым stateless потребует на порядок больше трафика и чуть больше методов в удаленном объекте, да и кода слишком много получается как на клиенте, так и на сервере...

IT>Этого не может быть

Может.


IT>Насчёт скорости, ты попробуй кеширование поиспользовать, очень сильно помогает

С кешированием полный порядок, кстати. Дейстивительно помогает, но не от этого.


Могу пояснить малость. Для поддержки stateless для каждого конкретного объекта на сервере нужно вводить и имплементировать специализированные методы по передаче контекстов и данных текущих прикладных операций. Т.к. речь идет о поддержке процесса редактирования, то для каждого из объектов нужно разрабатывать свои сценарии использования и поддерживать их как на клиенте, так и на сервере. В противоположность этому, statefull позволяет обобщить процесс передачи-кеширования. Т.е. движок сам точно знает, какие изменения он передал на сервер, а какие еще нет. На стороне самого сервера декларативно (аттрибутами) прописывается поведение отдельных порций данных.

Что мы получаем от всего этого? — действительно "тонкого" клиент. Абсолютно тонким он быть не может, разумеется иначе приложением будет неудобно пользоваться, однако, получается приличную часть логики по обслуживанию процесса редактирования объектов сосредоточить в одном месте — на сервере. Где, кстати, очень удобно выполнять различные вычисления, т.к. все "под рукой".

Насчет кеширования и траффика. Сейчас он минимален. Для того, чтобы достичь аналогичного в stateless потребуется потратить прилично кода для каждого аспекта каждого редактируемого объекта, требующего поддержки редактирования сервером. (Где поддержка со стороны сервера не требуется, там обе технологии дадут одинаковый трафик самих голых данных). Логика поддержки кеширования, зашитая в код (ведь мы должны вызывать вполне осмысленные методы удаленных объектов) — это кошмар для будущих изменений. Намного легче нам сейчас, где мы можем в очень широких пределах менять прикладную логику на сервере, практически не трогая клиента.

Здравствуйте, IT, Вы писали:

V>>Пример из жизни:
V>>- десятки девочек набивают накладные
V>>- накладные состоят в среднем из 100-300 строк (оптовая торговля бытовой химией), т.е. процедура набивки одной накладной довольно длинная
V>>- в системах типа 1С постоянно случаются накладки, когда несколько девочек пытаются одновременно продать остатки одной и той же позиции товара, ибо на момент набивки им всем система показывает наличие товара

IT>Действительно, такие задачи иногда встречаются в жизни. Но строить на основании этого всю систему как stateful — это нонсенс. Такую задачку надо выделить из общей массы, отвести её в сторонку (можно вместе с девочками) и там решить. Но только не надо обобщать подход к решению подобных задач на всё бизнес приложение в целом (если оно, конечно, не состоит из одной такой задачки).

Оно часто состоит из десятков подобных задач. Такие задачи я называю примерно так: "редактирование документов, требующее поддержки сервера". Складские и бухгалтерские задачи — как раз та область. Только по складу мы можем иметь до нескольких десятков операций (в наших реалиях, включая черно-бело-серое кино). И теоретически бесконечный набор черно-белых операций по бухгалтерии.

Большинство остальных задач учетно-аналитической бизнес-системы гораздо легче в реализации. Типа: справочники, отчетность (аналитика), ЗП и т.д. и действительно, не требуют statefull.

Все что далее просьба воспринимать не как размахивание флагом "statefull рулит всегда и везде", а как "иногда он очень удобен". Именно эти "иногда" и буду обсуждать, считая, что с бенефитами stateless и так все ясно.

V>>В моей системе сервер приложений разруливал подобную ситуацию. Т.е. используя statefull модель накладных, он позволял оперировать не только остатками товаров на складах по результатам транзакций, но и мгновенными остатками, с учетом текущих редактируемых данных коллеги за соседним столом.

IT>Думаю, что можно было бы отделаться только кешированием твоих мгновенных остатков. Делать для этого statefull модель накладных скорее всего совсем не обязательно.

Ниже как раз был приведен пример такого решения, которое было первоначальным.

V>>Подобная задача может быть решена и через stateless, но весьма ненадежно.

IT>Не верю По большому счёту stateful от stateless отличается только лишь тем, что state в stateless всегда гарантированно ложится в базу данных, а в statefull не всегда, иногда только в память апп-сервера. Остальное — это приёмы использования кеша и борьбы с ним.

Да все правильно. Но я не понимаю, для тебя принципиальная разница — где хранится промежуточное состояние — на сервере приложений, или на клиенте. Я помню, про off-line клиентов, но это совсем другая история, требующая персистентности уже прямо на клиенте для качественной реализации.

V>>(Именно таким был первый вариант решения задачи). Т.е. суть решения состояла в организации доп. состояния документа — черновик, и каждая строчка накладной отправлялась на сервак. Был общий регистр "набиваемых" данных. Вроде все работало, до тех пор, пока девочки корректно выходили из клиентских программ. Если же из программы вышли неккоректно в момент набивки накладных, то вся логика просто слетала. Приходилось наверчивать доп. операции, типа — сброс регистров набиваемых данных, эту операцию нужно было выполнять в тот момент, когда никто не редактировал накладные... И вся эта пляска вокруг однойтолько бизнес-задачи. В общем, наглядная демонстрация процедуры удаления гланд при неправильной начальной предпосылке расположения оных.

IT>И как ты удаляешь эти гланды теперь?

Удаляются сами. Удаленные (в смысле remote) объекты в .Net имеют время жизни. Корневым спонсором для удаленных объектов у нас является логическая сессия. Ее получает клиент при логине. Ее-то родимую мы и пингуем с некоторым интервалом. Если отвалились, можем заново восстановить соединение с собственной сессией и удерживаемыми объектами. Если компьютер девочки "отвалился" навсегда, то все созданные statefull объекты просто подбираются .Net remoting-ом через некоторое настраиваемое время (15 мин — оптимальный был для нас интервал). Соответственно, актуальные редактируемые остатки корректируются. Опять же — сами эти регистры теперь хранились в памяти сервера, поэтому задержки на обработку текущей редактируемой накладной стали просто незаметны на глаз. ("Хорошая" девочка гонит около 2 строк в секунду при набивке своей простыни, а таких девочек десятки, техника была — пень-III 800MHz, на stateless и триггерах работало, прямо скажем, не очень, зато стало весьма резво работать на statefull)

Кстати, именно для подобных накладных были задествованы все способы поддержки, включая полу-offline. На клиенте была предусмотрена персистентность, чтобы в случае обрыва связи не потерять сотни введенных строк. Допускалось продолжать редактировать эту накладную вне связи с сервером (список/иерархия товаров кешировался/синхронизировался на клиенте сразу при открытии первой же накладной. Синхронизировался — т.к. был тоже персистентным).

Были, разумеется, документы, которые не требовали поддержки сервером. В этом случае stateless получался сам-собой, даже при использовании нашего движка, заточенного под statefull. Просто когда данные передаются и сохраняются одной командой, то такое поведение аналогично stateless. Почему я и говорил, что реализация statefull более гибкая, т.к. позволяет получить любые модели поведения.

Т.е., я не напираю на statefull, я против того, чтобы от него отказываться. Особенно, если на нем неокторые вещи решаются легче.


V>>Статефулл решил все проблемы сразу, просто и элегантно.

IT>Неужели stateful штрафует девочек за некорректный выход из программы?

Он корректно "прибирает" за ними.

V>>Правильная тема для обсуждения. Свой енжин пишу как раз и для подобных задач. Дело в том, что мы, разработчики, обычно точно знаем характер взаимодействия со своими данными, а сервак SQL — нет. Справочники я обычно смело кеширую на апп-серваке, и уверяю, эти join-ы работают гораздо быстрее, чем на стороне SQL. Если решать задачу не каждый раз заново, а именно решить единожды — то все получается ok.

IT>Советую пользоваться индекстами
Хороший совет
Только все-равно быстрее без join-ов в БД.

IT>Впрочем, для монстрообразных справочников кеширование здорово помогает. Но, как я уже сказал выше, это с успехом и с теми же проблемами делается как в stateless, так и в stateful. Разницы никакой.

Вообще-то да. Просто в statefull используется единый механизм для синхронизации локальных кешей и состояний редактируемых объектов. Если посмотреть немного свысока — то это суть одно и то же.

V>>Кеширование бывает не только на апп-серваке, но и на клиенте. В статефул-модели мы можем поручить нашему движку самому разбираться, какие данные надо подгрузить на клиента, а какие не надо. То же самое при отправке их обратно на сервак. В случае медленного коннекта клиента — это сильное подспорье. Даже в случае быстрого, но тарифицируемого за каждый MB трафика — тоже.

IT>Могу ещё раз сказать про кешь — в обоих подходах с ним работа практически идентична.

Нет, не идентична, в случае, если ты редактируешь объект, который имеет как подчиненные так и связанные списки объектов.

Внимание, сейчас еще раз повторю, где именно получается выигрышь по трафику (уже обрисовывал как-то, видать не очень внятно и подробно).

Предположим, что мы редактируем объект, который содержит ассоциированные списки других объектов. Итак, суть редактирования объекта — задать как поля самого объекта, так и набить несколько ассоциированных списков (конкретно у нас — каждое задание включает список компьютеров, групп, ПО). Затем, ДО запуска задания необходимо проверить его на коректность. Соответственно, все данные объекта и подчиненные списки мы гоним на сервак. Сервак отвечает, что там-то и там нестыковка, — оператор подправляет нестыковку и опять пытается запустить задание. Так вот, все последующие разы мы посылаем задание не целиком, а лишь последние изменения — разрыв ассоциации, или добавление, или только лишь измененные поля.

Далее. Возвращаясь к тем же накладным. В случае stateless у нас были танцы с бубном насчет блокировок документов. Т.е., девочка набивала документ, время от времени она давит на [Save], текущие данные сохраняются в БД как черновик документа, НО, пока она не закрыла форму или не "отвалилась", мы знаем, что этот документ кто-то редактирует. (Кстати, при каждом [Save] на сервер посылаются... да-да, именно лишь последние изменения).

При первоначальной реализации stateless, в случае, если девочка "отвалилась", мы должны были как-то снимать блокировку с подобных документов. В нашем случае у админа был специальный тул, который позволял ему снимать блокировку с залоченного документа. К сожалению, это происходли довольно регулярно, и выглядело как элементарная недоработка (фирма-заказчик экономила на UPS-ах, а нам повезло внедряться, когда в соседнем корпусе этой фирмы шли строительно-сварочные работы ) .

У нас была еще одна вообще уникальная фича — совместное редактирование документа. Есть задача — внос остатков склада/торговой точки. Имеем более 5 тыс. позиций. Некоторые документы (конкретно — инвентаризация и отчет розничной точки) можно было открывать в режиме совместного редактирования. 5 девочек вполне нормально работали над одним документом. Как это адекватно разрулить в stateless, учитывая "отваливания", синхронизацию своих и чужих вносимых данных так, чтобы не гнать бесконечный документ целиком каждому из участников и т.д. — непонятно вообще.

IT>За исключением, пожалуй, одной вещи. В stateful кешь легко превращается в storage объектов в памяти, что при всей своей привлекательности несёт в себе массу других проблем.

Нет, кеш — это просто кеш. Как я говорил, у нас есть несколько политик, одна из которых — без кеша вообще. Задача кеша на апп-серваке — это именно оптимизация работы с хранилищем, и не более того. Если запрашиваемого объекта нет в кеше, то он загружается из БД (и оседает в кеше, если политика позволяет).


IT>>>Не так. Ты путаешь понятия cache и storage. Да, они оба как бы типа хранят состояние. Но наличие данных в первом совсем не обязательно и предназначено только для одной функции — снятие нагрузки с базы данных постредством реиспользования ранее произведённых запросов. Для второго — наличие данных это часть логики. Например, через кэш можно получить два разных экземпляра одной и той же записи БД. Для stateless в этом нет ничего страшного. Но, если твоё хранилище в stateful вернёт два экземпляра одного и того же объкта, то это уже не stateful, а либо глючный stateful, либо stateless

IT>Ну да, видишь, я об этом ещё два года назад говорил

V>>Правильное замечание. Для этих целей у нас отделены Entity от EntityView. Entity может быть только в 1-м экземпляре в кеше или не быть вовсе. Экземпляров EntityView может быть много. Всю потоко- и транзакционную безопасность они разруливают м/у собой сами.

IT>Ok. Пример из жизни. Загружаешь ты, например, накладную. Вместе с ней поднимается и товары. Товаров в базе данных мильёны. Грузить их все в кешь не имеет смысла. А может и имеет для каких-то случаев В любом случае какие-то товары у тебя уже в памяти. Теперь в другой части приложения ты делаешь запрос по какому то критерию для получения списка товаров. В качестве результата приезжает список как закешированных, так и не закешированных товаров. Что ты делаешь в этом случае? Мне правда интересно. Я занималься в своё время такой фигнёй, задача решаемая, но как-то глядя на это всё плакать хочется.

Если интересуют подробности, то вот они:

— кеш товаров (и некоторых других "объемных") справочников на стороне клиента — персистентный. (такая политика клиентского кеша, выполнен на MS Access, структура таблиц создается динамически, т.к. есть вся мета-инфа)

— каждый кешируемый тип объектов объект в системе имеет свой syncId, для кажой сущности он нарастает линейно при каждом сохранении в БД. Т.е. некоторые сущности (и их менеджеры) просто унаследованы от некоей базовой, поддерживающей синхронизацию. (можно не буду рассказывать, когда и как syncId сбрасывается).

— при открытии любого документа, содержащего справочные данные с выставленной политикой синхронизации (добавлю, у нас есть политики синхронизации/кеширования без персистентности, скажем, если объектов планируется до тысячи, то просто при первом обращении они грузятся в кеш, политику всегда можно поменять в run-time). Так, в при открытии документа производится синхронизация, т.е. просто клиент запрашивает данные с syncId большим, чем при последней синхронизации, последний syncId разумеется запоминается для последующих синхронизаций.

— в политике прописан интервал синхронизации. Обычно 0..30 сек (в зависимости от "критичности" актуальности), т.е. если с момента последней синхронизации прошло меньше времени, чем в политике, то синхронизация не нужна. Сама синхронизация выполняется не по таймеру, а именно по требованию, и запоминается время синхронизации.

— Если на сущность прописана политика подобной синхронизации, то сервак присылает вместе с ID так же и FriendlyName, т.е. пользователь открывает документ, обычно первые 1-2 сек окидывает его взглядом (а там все уже есть), или просто подводит мышку к нужному полю, за это время успевает происходить синхронизация, даже если этой рабочей станцией не пользовались несколько дней. При постоянной работе синхронизация занимает незаметное глазу время. Так вот, пока он подведет мышку к полю корреспондентов, эти корреспонденты уже синхронизированы на клиенте и их можно выбрать из dictionary.

— На клиенте кешируются, разумеется, не все поля объекта, а только лишь помеченные. В подавляющем большинстве { ID, FriendlyName }

повтор:
IT>В качестве результата приезжает список как закешированных, так и не закешированных товаров
Конкретно товары приезжали без FriendlyName (потому как, с одной стороны, довольно часто синхронизировались, с другой стороны — очень большие накладные бывали, по модему не очень оперативно получалось работать). Вместо отсутствующих имен ничего не отображалось менее секунды, потом отображалось.

Если в первый раз на данном десктопе запускали программу, то первая накладная открывалась заметное время (более 30 сек) при размере справочника товаров 5 тыс и все это по модему 33kb. Зато потом — весьма адекватная работа, незаметно, что по модему. По локалке — менее 2 сек.


-----
Да, еще один момент про statefull.

Было обнаружено, что уменьшение разрядности ID ВСЕХ справочников до 16 бит неплохо сказывается как на производительности БД (примерно в 4 раза быстрее стали перепроводится складские документы и строится отчеты), так и на работе по медленным каналам. Вопрос вылета за диапазон, при постоянном добавлении/удалении решался вводом сервиса счетчиков, которые выделяли ID-шки, и дополнительного кеша, куда складывались ID-шки удаленных объектов. Т.е. я исходил из предположения, что вряд ли будет более 65536 клиентов или сотрудников или товаров. (идентификация объектов не сквозная, разумеется, у кажого типа объектов — свой счетчик)

ID-шки выделяются централизованно сервером приложений. Для уменьшения количества глупых запросов за каждой ID-шкой, можно запрашивать сразу несколько штук. Было бы неплохо гарантировать затем возврат всех неиспользованных ID-шек при неккоректном завершении программы. И опять, наличие сессии и знание об существующих statefull-объектах позволяет корректно их удалять, и возвращать все что нужно куда нужно.

V>>Конечно StateFull. Ибо любой statefull легко приводим к stateless.

IT> Ты это серьёзно? Может мы используем разные термины? Ты под stateful понимаешь то, что я под statless, а я под stateful, то что ты под stateless?

Маловероятно. Я просто имел в виду режим "сквозной работы" statefull-объекта. У нас значения FirstName и LastName запрашиваются у EntityView, а не самого Entity. Конкретная имплементация конкретного EntityView может представлять из себя "сквозняк" и не иметь собственных состояний. У базового EntityView есть св-во Entity, так вот — оно виртуальное

Более того, сигнатура метода такова:

VariantT[] GetFieldValues(short[] fieldIds);

Если список fieldIds пуст — то просто получить значения всех полей.

Для отправки обратно значения полей есть 2 сигнатуры:

struct FieldValue { short FieldId; VariantT value; }

void SaveEntity(VariantT[] fieldValues);
void SaveEntityFields(FieldValue[] fieldValues);

Какую сигнатуру выбрать — решает движок с клиентской стороны в зависимости от того, какие поля редактировались и какие там сейчас данные, в общем — минимизирует траффик.

(Есть аналогичные методы SendEntity, SendEntityFields)

------
Иногда мы получаем stateless просто вот благодаря сценариям использования. Т.е. просто поднимаем объект (получаем ссылку сразу вместе с данными, см. ниже перегрузки методов), потом просто сохраняем одним движением. ВСЕ. Такой же stateless, только в профиль.

struct ObjectWithValues {
    IEntityWrapper entity;   // удаленный объект
    VariantT[] fieldValues;  // его поля
}

ObjectWithValues GetObjectWithValues(ObjectIdT objId);
IEntityWrapper GetObject(ObjectIdT objId);

В большинстве случаев используется первый вариант, т.е. мы получаем объект за одно действие, и за одно действие его сохраняем. Это один из типичных сценариев.

По сигнатурам методов видно, что они не предназначены для непосредственного использования (short fieldId). на стороне клиента есть EntityAdapter, к которому мы биндимся так же, как к DataView, и который скрывает все тонкости работы с апп-серваком, пользуясь мета-информацией. Которая, кстати, тоже кешируется


IT>Вот простой вопрос. Как ты превратишь stateful решение в масштабируемое?

Масштабирование — тот самый тонкий и весьма отдельный вопрос. Т.е. мне вполне понятно желание сделать масштабирование не напрягаясь особо. А что — элементарно поставил кластер БД, прилепил к нему несколько stateless App-серваков, и радуешься жизни. Предлагаю при масштабировании напрячься, но только чуть-чуть. Приведу свой же ответ на подобный вопрос:

Да не бывает полностью statefull-приложений. Система управления предприятием может иметь сервисы внутри апп-сервака, которые представляют из себя stateless. Просто редактирование связанных документов — это именно та область, где очень неплохо работает statefull, и очень сложно добиться адекватного поведения от stateless. Я бы разбил логику сервера приложений на несколько составляющих:
— бизнес-сервисы, т.е. некие статические бизнес-методы или методы статических объектов, которые выполняют операцию за один вызов, тут у всех волей-неволей получается stateless
— поддержка редактирования документов, здесь statefull рулит, т.к. иногда может потребоваться прилично информации для поддержки процесса, и эту гору информации необязательно гонять каждый раз на клиента.

Соответственно, когда речь заход о масштабируемости, то учитываем свою специфику. Например, сервисная часть легко поддается "тупому" масштабированию. Statefull-часть может работать вообще на отдельном сервере приложений, если очень надо... В принципе, там большая скорость обычно не требуется, ибо люди вносят/изменяют информацию крайне медленно с т.з. выч. систем. А отчетность и аналитика сидит на сервисах, т.е. на других хостах в нашем случае. Если же мощности все-равно не хватает, то я бы разбил бизнес-задачи на несвязанные или слабосвязанные наборы документов, и распределял бы нагрузку именно таким образом — согласно уровню связанности.

V>> У нас в системе есть несколько сущностей, которые ведут себя как stateless, потому как на каждый чих скидывают свое сосстояние в БД (и в кеш соответственно). Владение разными экземплярами EntityView одним экземпляром Entity автоматичеки синхронизирует изменения в соседних клиентских сессиях.

IT>Какой же это stateless? Типичный stateful, только с гарантированным сохранением данных в БД.

И с гарантированным получением оттуда (либо из ОБЩЕГО кеша). Какой же это statefull? Или я чего-то недопонимаю?

IT>>>>>То ли в память, то ли в процессор. И не надо говорить что сейчас памяти навалом. Возьмём хотя бы наш сайт, у нас данных в базе на гиг, но если это всё положить в память, в виде найс объектной модели, то сервер сразу ляжет, т.к. под это понадобится в разы больше памяти чем используется БД.

V>>Всю модель никто и не ложит в память. Обычно настраивают политику использования кеша для каждой сущности. Для справочных данных — это было бы оправданно почти всегда, для остальных — в зависимости от задачи.

IT>Для остальных вообще как правило ничего не имеет смысла кешировать.

Когда куча сущностей взаимодействует и ссылается друг на друга, то трудно определиться — какая из них справочная, а какая — нет. Практически каждая осмысленная сущность — справочная. Ввиду этого я вводил 2 уровня кеширования:
— { ID, FriendlyName}
— вся сущность.

Не пытался кешировать только движения.

В бухгалтерии, однако, полезно кешировать даже движения, если организовать разделение м/у актуальными данными текущего периода и прошлыми данными. При наличии кеша, такое разделение даже не требуется отображать в БД и иметь тонну гемора всвязи с этим (один из гемморов в 1C, Accent, R-base). Т.е. при старте app-сервака просто высчитываем (или загружаем) состояние регистров на начало периода и подгружаем движения от начала периода до текущей даты. Очень прекрасно начинает работать оперативная бухгалтерская отчетность. Для банка я бы установил период в 1 банковский день.

IT>>>Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы

V>>Скажем прямо — когда как. Стоит захотеть положить на форму полнофункциональный грид — и сразу прощай веб-форма в ГУИ. Да и вообще, при интенсивном взаимодействии на клиенте с этим ГУИ неудобно работать с embedded web-form, гораздо проще оперировать обычным Windows.Forms.

IT>Разве? А где ты видел нормальный грид для гуёв? Веб-грид хоть и простенький, но с ним можно практически всё делать. А что нельзя, можно на таблицах. Думаю, кода будет не больше, чем при кастомизации гуёвого грида.

Нормальный — это Infragistics, например. У меня накопились доработки к нему (благо, он представляет из себя практически конструктор, и очень мощный). В общем, мало кода обычно, учитывая богатство мета-информации. В 99% процентов мне было достаточно подать ему (моей версии этого грида) источник данных и забыть. Остальное происходит автоматически.

V>>Хотя, в своем редакторе запросов взяли именно WebForm, и прилично натрахались со сложным взаимодействием с ней... И все только из-за мощных ср-в управления layout-ом.

IT>Вы наверное стремились всё сделать pixel-perfect?

Да нет, просто сам характер взаимодействия специфичен. Идет текст по ресайзэбл-форме, участки текста выделены цветом и подчеркиванием при наведении. Рядом со скобками идет кнопочки. Все это должно лэйаутиться и переноситься на новую строчку и т.д.

IT>>>>>Масштабируемость в стэйтфул — это вообще занятие для мазахистов. Сложность приложения из-за синхронизации увеличивается в разы.

V>>Все ясно. Вопрос вообще о подходе к написанию многозвенных приложений. С тем, что statefull изначально проще в реализации простых операций, типа: прочитать, изменить, записать, никто и не спорил. Однако очевидно, что с помощью statefull становится сложновато строить приложения, где необходима мгновенная реакция на изменения в системе, вызванные "соседним" пользователем. Применяя stateless вообще сложновато координировать м/у собой действия различных пользователей в системе, если таковая задача вдруг встанет. И этот принцип я бы не стал делить по применимости на Web- или GUI-приложения. On-line GUI клиента к RSDN я бы тоже выполнил в виде stateless модели. Однако WEB-формы выписки накладных из приведенного выше примера — однозначено statefull.

IT>Я уже сказал, что такой класс задач гораздо реже встречается в природе чем "простые операции типа: прочитать, изменить, записать". Да и такие задачи можно и нужно раскладывать на простые операции и в результате там от stateful останется один простой список текущих остатков. Ты же, похоже, создав целый фреймворк для твоей задачи, пытаешься не только обобщить это всё на весь stateful, но и убедить всех, что это единственно правильное решение. Это не так. Уверен, что твою задачу можно было бы спокойно решить малой кровью без строительства завода для производства одного гвоздя.

Не знаю, не знаю. В приведенном примере перешли на statefull именно из-за побочных эффектов в случае неккоректного завершения клиентского приложения, ненадежных блокировок документов и т.д.

Т.е. пришли к этому не сразу, а после месяцев реальной эксплуатации.