Подходы к организации 3-tier - Архитектура программного обеспечения

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

AVK>Извини за философию, но что то меня сегодня на конкретику не тянет

. Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом

Ok. Но все видели, это не я начал

AVK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.

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

AVK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.

Было бы здорово, если бы ты привёл пример когда без этого не обойтись.

AVK>А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтлес? Это самый натуральный стейтфул, только реализованый на основе стейтлес технологий коммуникации при помощи доставания гланд через неожиданное отверстие.

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

AVK>Стив Шварц, один из архитекторов СОМ+, а теперь наверное индиги, когда приезжал в Москву сказал примерно следующее:
AVK>никаких стейтлесов не существует в природе. Любой вариант это стейтфул. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".

Грамотный мужик. Всё правильно говорит. Вопрос только в том как теперь его мысль интерпретировать.

AVK>А дальше начинается самое интересное. Заученное "стейтлес всегда лучше масштабируется" оказывается не всегда верным! Нет, оно так если все данные под гребенку отнести либо к стейтлес, либо к стейтфул модели. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д.

Ok.

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

Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

AVK>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.

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

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

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

AVK>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.

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

AVK>Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.

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

На самом деле я вовсе не так против стэйтфул как ты против стэйтлес

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

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

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

И еще раз спасибо.

Мнения двух сторон — лучшая пища для размышлений.

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

AVK>>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.

IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.

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

IT>Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова.

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

IT> Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.

А это палка о двух концах. Тут и без клонирования ясно — основная проблема стейтлес систем — изоляция, стейтфул — синхронизация, вне зависимости от наличия / отсутствия клонирования.

AVK>>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.

IT>Было бы здорово, если бы ты привёл пример когда без этого не обойтись.

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

AVK>>А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтлес? Это самый натуральный стейтфул, только реализованый на основе стейтлес технологий коммуникации при помощи доставания гланд через неожиданное отверстие.

IT>Удаление гланд через отверстие так же как и ремонт клапанов через выхлопную трубу никогда не было весомым аргументом.

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

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

IT>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

Счего бы это? Стейтфул модель как правило характеризуется еще и тем что у нее имеются расширенные метаданные бизнес-логики, т.е. значительно больше информации о предметной области, нежели у sql-серверов. Кроме того серверу приложений нет необходимости быть универсальным, его как правило задачивают под узкий круг задач. Отсюда механика управления на сервере приложений более оптимальна. Оптимизацией запросов при помощи сервера приложений можно добится эффективности кеша на не очень часто меняемых данных в районе 99% и практически полного отсутствия блокировок в БД. Это результаты реальной системы. Сервер же БД в такой схеме периодически получает интенсивные и кратковременные плевки.

AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.

IT>Ерунда.

Может и ерунда но именно так оно выходит на реальных серверах.

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

Самой стейтлес блокировки не нужны, о том и речь. Вся тяжесть изоляции в этом случае ложится на сервер БД. А вот ему то как раз и приходится несладко.

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

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

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

AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.

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

Я не писал о задачках вроде нашего сайта. Я ж говорю что ты там совсем отвык от нашей действительности

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

AVK>>Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.

IT>Обращение может и не требует, а изменение требует по полной схеме.

Вот нифига подобного. Сложность синхронизации изменений ложится на сервер приложений, а не на его логику.

IT>И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.

Пока не понадобится хранить состояния

.

IT>На самом деле я вовсе не так против стэйтфул как ты против стэйтлес

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

Смею повторится — задачки бывают разные. Если данные по большей части быстро устаревают стетфул модель будет неэффективна, если наоборот неэффективной будеть стейтлес модель. Рулит, как всегда, помимо тактического ядерного заряда конечно, золотая серидина. Т.е. грамотное, с учетом предметной области, распределение между стейтфул и стейтлес, причем желательно без явной границы, т.е. чтобы каждый объект в определенной пропорции был и стейтлес и стейтфул.

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

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

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

Не все так однозначно. Ровно так же резко усложняется проблема со стейтлес при больших нагрузках из-за лавинообразного нарастания блокировок в БД и ровно такой же геморой начинается при оптимизации этой самой БД и запросов к ней. Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.
Мне как то не приходилось пока делать системы под очень большую нагрузку, так что может поэтому я так скептически отношусь к чисто стейтлес модели.

IT>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой.

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

... << RSDN@Home 1.1.2 beta 1 (Win32NT 5.1.2600.0) >>

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

AVK>>Извини за философию, но что то меня сегодня на конкретику не тянет

IT>Ok. Но все видели, это не я начал

Ага.

AVK>>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.

IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо. Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова. Альтернатива — клонирования, но здесь неизбежно упираемся в синхронизацию и версионность.

AVK>>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.

IT>Было бы здорово, если бы ты привёл пример когда без этого не обойтись.

Гхм. Отвечу по своему... ммм... опыту.

Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности. Например, ЦПУ может работать с памятью без кэшей L0-L2? Без конвейеров?

Может! Только общая скорость обработки упадёт.

[...]

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

В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.

[хрум]

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

IT>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

Ты о чём?

Откуда обобщения?

AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.

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

Блокировки автоматом реализуются SQL-сервером. Ну не dirty-read же, в самом деле!

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

Т.е., по сути — превращение stateless в stateful?

Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.

AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.

Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.

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

Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится.

IT>На самом деле я вовсе не так против стэйтфул как ты против стэйтлес

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

Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.

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

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

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

Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель.

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

IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.

Надо, но у тебя не размазано хранение состояния по двум максимально удалённым точкам — серверу БД и клиенту. Следовательно, есть возможность оптимизировать нагрузку на коммуникации. Следовательно, можно даже восстановить состояние клиента в полном объёме при обрыве/восстановлении связи "клиент-сервер", не привлекая к этому сервер БД.

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

В сущности — да, и как раз клонирование появляется при размещении stateful-App-ядра (эк, термин-то

Hello, "Геннадий Васильев"
>
> Гхм. Отвечу по своему... ммм... опыту.

Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности.

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

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

>
> В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.
>

Глубоко сомневаюсь на счет эффективности. stateless модель будет легко масштабироваться просто добавлением еще одного сервера. Для statefull это окажется достаточно не тривиальной задачей и рано или поздно — приложение упрется в физические возможности конкретной машины. Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п. Хотя, для не критичного приложения уровня подразделения — использование statefull модели — это разумный выбор.

> AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.
>

Для редко меняемых данных — второй SQL сервер и online репликация. Зачем зацикливаться на масштабировании сервиса, в большинстве случаев — многие из этих задач может на себя взять база данных.

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

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

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

>

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

> AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
> IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
>
> Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.
>

Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.

> AVK>>[...] не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
> IT>Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.
>
> Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится.
>

Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.

Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.

> Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.

>

Кеш и внутреннее состояние — это несколько разные вещи.

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

Причем — все это понимают и именно по этому становится популярной SOA

Posted via RSDN NNTP Server 1.8 beta

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

AVK>>>О, это большой и сложный вопрос

iT>>Менее интересно не стало

Да я понимаю

Просто что то сейчас настроения нет на такие темы распространяться, отдыхаем-с от программирования.

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

Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтфул? Это самый натуральный стейтлесс — только в данном случае его реализация напоминает поведение стейтфул модели. А так, типичный стейтлесс — вызвали метод, он отработал, сбросил результаты и все — мы про него забыли. Реализация — же подобной функциональности через стейтфул — напоминает доставание гланд через неожиданное отверстие.

Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее:
никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода). В остальном, стайтфул, стайтлесс — это одно и тоже. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".

А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д. что в общем-то не открытие америки.

Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь стейтлес моделью — проявляется во всей своей красе — получили данные, чуть-чуть обработали и забыли. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных есть большой соблаз запишхуть их в кеш и получить мощную отдачу от хорошего, современного сервера. А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую. А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша. Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции (все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные... И в итоге — стайтфул модель оказывается плохо масштабируемой. добавить просто так еще один сервер нельзя — нужно обеспечить согласованность внутренних кешей и т.п. остается — только наращивать производительность одной конкретной машины или вводить элементы stateless модели.

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

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

Извини за философию, но что то меня сегодня на конкретику не тянет

. Теперь осталось дождаться ответной философии от AVK в защиту стейтфул модели и неделя будет завершена достойно целым философским трактатом

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

TK>Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.

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

TK>Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.

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

TK>Причем — все это понимают и именно по этому становится популярной SOA

Пока что только на языке у маркетологов МС.

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

Можно процитировать по нормальному, а то прочесть не смог?

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

>> Гхм. Отвечу по своему... ммм... опыту.

Без stateful обойтись можно практически всегда, только цена такого решения — потеря эффективности.
TK>Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.

Это зависит от топологии сети. Межсерверный трафик может быть физически отделён от клиент-серверного, а сам по себе он отнюдь не велик, можешь посчитать. Особенно, если учесть, что между серверами нужно гонять только изменения состояний и кое-какую управляющую информацию. Если, конечно, это не SOAP-вызовы.

Главная причина потери эффективности в stateless-модели состоит в том, что почти всегда в обработку вовлекается сервер базы данных, то есть этот "пирог" из клиента, app-сервера и сервера БД всегда "прорезается насквозь", и очень хочется этого избежать.

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

>>
>> В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.
>>
TK>Глубоко сомневаюсь на счет эффективности. stateless модель будет легко масштабироваться просто добавлением еще одного сервера.

Это — да.

TK>Для statefull это окажется достаточно не тривиальной задачей и рано или поздно — приложение упрется в физические возможности конкретной машины.

Это тоже в принципе верно, но для того в stateful-систему и добавляются механизмы синхронизации кэшей, хитрый арбитраж блокировок и т.п. Естественно, что мощности одной машины может и не хватить.

TK>Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п.

Откуда такое утверждение? Это совершенно необязательно.

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

TK>Хотя, для не критичного приложения уровня подразделения — использование statefull модели — это разумный выбор.

>> AVK>>А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.

TK>Для редко меняемых данных — второй SQL сервер и online репликация. Зачем зацикливаться на масштабировании сервиса, в большинстве случаев — многие из этих задач может на себя взять база данных.

Хммм... Про репликацию в данном контексте не согласен ни разу. Если её использовать для обеспечения зеркальности параллельно используемых данных, то всегда есть вероятность влететь строго в промежуток между репликациями. Ну уж не-е-ет...

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

TK>Если использовать этот пример, то можно посмотреть на OODB. Казалось-бы уж кто лучше должен знаеть о том, как устроена объектная модель приложения. Но, где хоть один достойный пример реализации (из тех, что может посоперничать с RDBMS)?

Сейчас навскидку не скажу, помотри где-то cetus-links был документ из серии "XX мифов об объектных базах данных".

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

>>
TK>Наличие кеша — это еще не признак наличия состояния. Преимущество stateless это в аттомарности операций и в том, что никакого промежуточного состояния не сохраняется памяти сервера. т.е. после того, как была выполнена stateless опарация — мы можем забыть о конкретном frontend сервере и следующий запрос может быть с тем-же успехом обслужен любым другим.

Ну вот, кстати, как раз та самая подмена понятий, о которой упоминал AVK. Как ты реализуешь атомарную операцию, если она растянута, к примеру, на 30 минут? На все 30 минут блокируешь данные? Нет, конечно. Ты разбиваешь её на серию более мелких, отмечающих промежуточные, т.е., недолговременные состояния системы. Таким образом, реализуется в десяток раз больше обращений к БД, чем в случае, когда промежуточное состояние хранится в памяти App-сервера и записывается только одно — последнее изменение. А в случае stateless, мы получим по сути, тот же stateful, но "под микроскопом", где из-за каждого чиха появляется серьёзная програмисткая задача.

>> AVK>>Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
>> IT>Ну это так показывает твоя практика. Возьми хотя бы наш сайт, в нём вообще нет долго живущих данных.
>>
>> Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.
>>
TK>Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.

Вот и плохо, что они хранятся только в БД.

ИМХО, разумеется. Если бы они выстраивались в памяти, то общая вычислительная нагрузка на сервер была бы меньше. И не надо говорить, что это потребовало бы очень много памяти. Даже если у нас миллион сообщений, то для того, чтобы затолкать в память все соответствующие деревья сообщений нужно ~16 * 10^6 байт — т.е., всего-то около 16 мегабайт.

И с другой стороны — дерево сообщений это и есть один из типов объектов.

>> AVK>>[...] не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.
>> IT>Обращение может и не требует, а изменение требует по полной схеме. И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.
>>
>> Да, как минимум, нужно озаботиться эффективной реализацией Single-Write-Multiple-Read-объектов. Плюс к тому — механизмом синхронизации данных в кластере, буде таковой случится.
>>

TK>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.

Угу, только с привлечением БД всё это работает намного медленнее, чем в памяти App-сервера, хотя бы как минимум в силу того, что для обращения к этому объекту задействуются драйверы БД, паковка/распаковка SQL и т.п. Не говоря уже о том, что в пределе вся бизнес-логика улетает в ХП+триггеры...

TK>Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.

Да хоть груздь чешуйчатый.

Суть-то проблемы не меняется: необходимо организовать согласованную работу нескольких компьютеров.

>> Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.

TK>Кеш и внутреннее состояние — это несколько разные вещи.

Всё зависит от того, что именно в этом кэше лежит. Если это просто записи БД, то — да, если предварительно созданные объекты, то нет.

PS. 2 Moderator, извините за оверквотинг.

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

AVK>Здравствуйте, TK, Вы писали:
AVK>Можно процитировать по нормальному, а то прочесть не смог?

Это не цитата

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

TK>>Все зависит от того, как реализации statefull модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.

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

ты-же не различаешь statefull / stateless только местом хранения данных? Рано или поздно все данные попадают в какое централизованное хранилище. stateless приложение не обязательно должно хранить свои данные "в канале". Никто не мешает организовать отдельное хранилище — главное, что сами stateless методы являются аттомарными — именно по этому данная архитектура лучше масштабируется.

TK>>Да и кластер — это уже давно пройденный этап. Сейчас в моде grid системы.
AVK>Мода еще не означает технической целесообразности. Веб сервисы вон тоже модны, только на практике толку от них немного.

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

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

AVK>>Можно процитировать по нормальному, а то прочесть не смог?

TK>Это не цитата

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

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

TK>ты-же не различаешь statefull / stateless только местом хранения данных?

Я различаю очень просто — есть состояние вне клиента — стейтфул, иначе стейтлес.

TK>Рано или поздно все данные попадают в какое централизованное хранилище. stateless приложение не обязательно должно хранить свои данные "в канале". Никто не мешает организовать отдельное хранилище — главное, что сами stateless методы являются аттомарными — именно по этому данная архитектура лучше масштабируется.

Проблема только в одном — как только тебе нужно будет откатить состояние в результате ролбека сразу попадаешь на очень большие неприятности.

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

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

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

TK>>Это не цитата

AVK>Да я понял, но уж больно много там прямого цитирования, разобрать очень тяжело.

Скажем так — это не цитирование, это просто демонстрация того, как можно теми-же словами написать про stateless.

Что-же касается statefull — IT тебя уже заклеймил

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

TK>Скажем так — это не цитирование, это просто демонстрация того, как можно теми-же словами написать про stateless.

Фиговая демонстрация если честно, сплошное передергивание

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

iT>Мнения двух сторон — лучшая пища для размышлений.

Причём, что самое интересное, я во многом разделяю любовь АВК к стэйтфул, но раз уж он мне навесил ярлык стэйтлещика, то будем его носить гордо

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

TK>>Скажем так — это не цитирование, это просто демонстрация того, как можно теми-же словами написать про stateless.
AVK>Фиговая демонстрация если честно, сплошное передергивание

В чем передергивание?

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

TK>>ты-же не различаешь statefull / stateless только местом хранения данных?
AVK>Я различаю очень просто — есть состояние вне клиента — стейтфул, иначе стейтлес.

Нет состояния только у reference реализации. В остальных случаях — это больше подход к тому, как это состояние хранить — можно в памяти сервера, а можно делать каждый метод максимально независимым.

AVK>Проблема только в одном — как только тебе нужно будет откатить состояние в результате ролбека сразу попадаешь на очень большие неприятности.

Какие неприятности? Если не делать сохранение данных "в лоб" то проблем никаких не возникнет.

AVK>Говоришь словами маркетологов. На практике область применения этих самых сервисов узенькая совсем.

Ага. Примерно как и у остального web.

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

AVK>>Можно процитировать по нормальному, а то прочесть не смог?

TK>Это не цитата

Злой ты, Тимофей.

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

TK>>Все зависит от того, как реализации stateless модели. Можно, как говорит AVK, гонять состояние по каналам передачи данных. Это не самый удачный выбор (хотя, если состояние небольшое, то это выход) каналы обычно не резиновые, и в данном случае все возможности масштабирования приложения просто упрутся в толщину канала.

ГВ>Это зависит от топологии сети. Межсерверный трафик может быть физически отделён от клиент-серверного, а сам по себе он отнюдь не велик, можешь посчитать. Особенно, если учесть, что между серверами нужно гонять только изменения состояний и кое-какую управляющую информацию. Если, конечно, это не SOAP-вызовы.

это я слово перепутал — stateless разговор был про реализацию хранения состояния на клиенте.

ГВ>Главная причина потери эффективности в stateless-модели состоит в том, что почти всегда в обработку вовлекается сервер базы данных, то есть этот "пирог" из клиента, app-сервера и сервера БД всегда "прорезается насквозь", и очень хочется этого избежать.

Не обязательно делать простой, трехслойный пирог. Слоев может быть несколько и в итоге каждое конкретное разрезание может и не доходить да самого последнего слоя.

ГВ>Это тоже в принципе верно, но для того в stateful-систему и добавляются механизмы синхронизации кэшей, хитрый арбитраж блокировок и т.п. Естественно, что мощности одной машины может и не хватить.

Вот именно — хитрые механизмы синхронизации, хитрые арбитражи. т.е. можно сказать, что синоним слова statefull это хитрый. В итоге сложность и стоимость системы растет слишком не пропорционально.

TK>>Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п.
ГВ>Откуда такое утверждение? Это совершенно необязательно.

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

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

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

ГВ>Хммм... Про репликацию в данном контексте не согласен ни разу. Если её использовать для обеспечения зеркальности параллельно используемых данных, то всегда есть вероятность влететь строго в промежуток между репликациями. Ну уж не-е-ет...

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

TK>>Если использовать этот пример, то можно посмотреть на OODB. Казалось-бы уж кто лучше должен знаеть о том, как устроена объектная модель приложения. Но, где хоть один достойный пример реализации (из тех, что может посоперничать с RDBMS)?

ГВ>Сейчас навскидку не скажу, помотри где-то cetus-links был документ из серии "XX мифов об объектных базах данных".

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

ГВ>Ну вот, кстати, как раз та самая подмена понятий, о которой упоминал AVK. Как ты реализуешь атомарную операцию, если она растянута, к примеру, на 30 минут? На все 30 минут блокируешь данные? Нет, конечно. Ты разбиваешь её на серию более мелких, отмечающих промежуточные, т.е., недолговременные состояния системы. Таким образом, реализуется в десяток раз больше обращений к БД, чем в случае, когда промежуточное состояние хранится в памяти App-сервера и записывается только одно — последнее изменение. А в случае stateless, мы получим по сути, тот же stateful, но "под микроскопом", где из-за каждого чиха появляется серьёзная програмисткая задача.

Это ты про использование BizTalk Server? Согласен, в случае со statefull стратегией — легко сорваться и начать все делать руками.

TK>>Все эти деревья никак не относятся к внутреннему состоянию объекта — они хранятся только в БД, а все представления в памяти это просто кеш.

ГВ>Вот и плохо, что они хранятся только в БД.

ИМХО, разумеется. Если бы они выстраивались в памяти, то общая вычислительная нагрузка на сервер была бы меньше. И не надо говорить, что это потребовало бы очень много памяти. Даже если у нас миллион сообщений, то для того, чтобы затолкать в память все соответствующие деревья сообщений нужно ~16 * 10^6 байт — т.е., всего-то около 16 мегабайт.

Скажи честно — зачем, нужно дерево сообщений в памяти? На клиента достаточно отдать топик — дерево он построит самостоятельно.

ГВ>И с другой стороны — дерево сообщений это и есть один из типов объектов.

А он точно нужен?

TK>>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.

ГВ>Угу, только с привлечением БД всё это работает намного медленнее, чем в памяти App-сервера, хотя бы как минимум в силу того, что для обращения к этому объекту задействуются драйверы БД, паковка/распаковка SQL и т.п. Не говоря уже о том, что в пределе вся бизнес-логика улетает в ХП+триггеры...

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

ГВ>Да хоть груздь чешуйчатый.

Суть-то проблемы не меняется: необходимо организовать согласованную работу нескольких компьютеров.

Oracle 10g. Не нужно никаких мощных серверов... просто ставим кучу машин уровня рабочей станции под линуксом.

ГВ>Всё зависит от того, что именно в этом кэше лежит. Если это просто записи БД, то — да, если предварительно созданные объекты, то нет.

Какая-то неувязочка... есть y = f(x) x — это записи, y это объект. f какое-то фиксированное преобразование. получается, что фиксированное преобразование + сырые данные это есть состояние? А если преобразование отложить?

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

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

Вот о том и речь что на практике никуда от стейтфул не деться, только приходится это делать при помощи нетривиальных http-сессий.

AVK>>Проблема только в одном — как только тебе нужно будет откатить состояние в результате ролбека сразу попадаешь на очень большие неприятности.

TK>Какие неприятности? Если не делать сохранение данных "в лоб" то проблем никаких не возникнет.

При чем тут в лоб? Ручная организация отката в бизнес-коде это совсем фиговая идея. Рассказать типичному бизнес-программисту что такое транзакция уже серьезная проблема, а заставить его реализовывать ролбеки совсем задница.

AVK>>Говоришь словами маркетологов. На практике область применения этих самых сервисов узенькая совсем.

TK>Ага. Примерно как и у остального web.

Что то пока не заметно этого остального, кроме сервисов, рассказывающих погоду по индексу на конверте. Круто конечно, но это все игрушки. Без транзакцию это все несерьезно.

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

ГВ>Гхм. Отвечу по своему... ммм... опыту.

Может! Только общая скорость обработки упадёт.

Может упадёт, а может и нет, всё зависит от задачи. Так в стэйтфул ты пытаешься решать проблему даже ещё не зная, существует ли она на самом деле. Оптимизацию запросов и кеширование в стэйтлес никто не отменял. Но делать это можно не только на этапе разработки, но и во время эксплуатации, наблюдая за поведением системы. А это означает прежде всего сокращение сроков разработки.

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

ГВ>В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.

Кто тебе сказал, что более эффективно

Оптимизаторы запросов реляционных БД шлифуются уже десятилетиями. Писать же выборку по двум-трём связанным бизнес сущностям в памяти ты будешь сам во время отведённое тебе на разработку. Оптимизировать этот запрос ты тоже будешь сам.

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

IT>>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

ГВ>Ты о чём?

Откуда обобщения?

Оттуда, откуда и у АВК. От балды.

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

ГВ>Т.е., по сути — превращение stateless в stateful?

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

ГВ>Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.

Синхронизация кешей по своей сложности — это амёба в сравнении с тем каких монстров приходится писать для синхронизации полноценных стэйтфул моделей.

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

ГВ>Хотя по сути-то они есть. Те же деревья сообщений и дерево форумов.

Ничего не кешируется. Не эффективно.

ГВ>Просто разумный баланс нужен. Никто не мешает, к примеру, кешировать заголовки сообщений, деревья сообщений и деревья форумов. Возможно, так оно и есть на самом деле, я ведь не знаю внутренностей www.rsdn.ru.

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

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

ГВ>Правда, и потребности в масштабировании уменьшаются.

Я как раз думаю что наоборот.

ГВ>Кстати, такую же необходимость в синхронизации ты получишь, когда будешь определять "намёк" на изменение данных, чтобы сбросить stateless-кэши.

Я же говорю — это делается на коленке. Могу привести пример дубового, но вполне эффективного и в то же время элементарного в имплементации решения. Хотя, я думаю, у тебя у самого таких предостаточно

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

ГВ>Скорее проблема в том, что сейчас практически нет App-серверов, хорошо реализующих stateful-модель.

И это наводит на серьёзные размышления

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

Ну ты силён, бродяга.

TK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стайтфул модели — состояние приходится хранить в памяти на сервере. Если размер такого состояния велик начинаются траблы, кончается ресурсы сервера, память. конечно, IA64 и AMD64 как герои диснея "спешат на помощь", но это все только в краткосрочной перспективе.

Ровно то же самое произойдёт с SQL-сервером. Как в том анекдоте: "Жить-то Win'95 на 4 мегабайтах будет, но и только". Ты очень и очень спешишь с обобщениями. Кроме того, хранение состояний в памяти это не "недостаток", как ты утверждаешь, а всего лишь черта stateful-модели. Недостатком оно становится в тех или иных случаях, не более того.

TK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий.

Угумс. А ещё мы наблюдаем попытку впарить BizTalk.

TK>Если мы скидываем данные в БД, то какой же это, к черту, стейтфул? Это самый натуральный стейтлесс — только в данном случае его реализация напоминает поведение стейтфул модели. А так, типичный стейтлесс — вызвали метод, он отработал, сбросил результаты и все — мы про него забыли. Реализация — же подобной функциональности через стейтфул — напоминает доставание гланд через неожиданное отверстие.

TK>Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее:
TK>никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода).

Но никак не пример stateless-объекта.

Напоминаю азы ООП: объекты суть состояния и методы, изменяющие состояния. Приведённый тобой пример — пример процедуры, а не метода.

Хотя да, такой метод может быть... например, статическим.

TK>В остальном, стайтфул, стайтлесс — это одно и тоже. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".

На самом деле вопрос несколько шире, чем просто хранение сотояний. Вопрос ещё и в методах обработки этих самых состояний. И кстати, тот ещё вопросик...

TK>А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта.

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

Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".

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

TK>Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее.

А вот это утверждение, кстати, спорно. Часто обновляемые данные можно обновлять в БД с некоторой задержкой, что уже само себе может дать некоторый выигрыш в общей производительности.

Здесь есть очень интересная деталь, про которую обычно принято забывать. Те же самые заказы, отгрузки прочая шелупонь прежде чем достичь места хранения сначала всегда создаются на одном из промежуточных или клиентском уровне. Исключение составляют случаи прямой связи клиента с сервером БД, но мы же не о них говорим, верно?

Так вот, использование stateful даже здесь позволит получить некоторый выигрыш. Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то. Опять-таки, можно, конечно, прокрутить ещё одну транзакцию в БД, она же у нас гибкая как змея и современная как космический корабль, но есть идея лучше: задержать накладную в памяти App-сервера на 180-300 секунд, тем самым освободив сервер БД от обязательных для него, но совершенно не нужных в контексте приложения транзакций. Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.

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

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

Кстати, подойдёт и не такой уж "мощный и современный". Несовременного вообще ничего нет. "Не бойся быть несовременным, это единственное, чего тебе не удастся." — (c) Сальвадор Дали.

TK>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.

Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.

TK>А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша.

Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД. Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется.

Конкретный App-сервер может ни шиша не знать о прикладной специфике.

TK>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции

Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.

TK>(все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные...

А вот это, кстати, косвенно подтверждает тезис о снижении производительности OLTP в stateless-модели.

Второе аналогичное подтверждение состоит в том, что в тестах TPC-C MS использовала COM+ только для чтения данных, а обновление запускались через обычный ODBC. Что, в принципе, логично, если рассматривать stateless-модель в её естественной ипостаси — как удобной модели для трансформации представления данных.

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

Ухх... в итоге получается нечто, достойное рекламной статьи на сайте Microsoft, уж извини. Ты утверждаешь, что нельзя обеспечить согласование кэшей? А на основании чего ты так говоришь? Уж не основании ли того, что у тебя в распоряжении нету компонента "StatefulCacheSyncronizer"?

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

1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.
2. Оверхед таки вносится.
3. Математический аппарат в хинтах... ммм... это даже не смешно.
4. Читается конечно, на одном дыхании, в этом не откажешь.

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

Угу, продажа BizTalk уже началась.

TK>Извини за философию, но что то меня сегодня на конкретику не тянет

Мда, неплохое воскресенье выдалось.

Hello, "AndrewVK"

>
> Что то пока не заметно этого остального, кроме сервисов, рассказывающих погоду по индексу на конверте. Круто конечно, но это все игрушки. Без транзакцию это все несерьезно.

Можно использовать BizTalk — он поддерживает и веб методы и транзакции.

Posted via RSDN NNTP Server 1.8 beta

Hello, "IT"
>
> Злой ты, Тимофей.

OK. Но все видели, это не я начал

Posted via RSDN NNTP Server 1.8 beta

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

iT>>Мнения двух сторон — лучшая пища для размышлений.

IT>Причём, что самое интересное, я во многом разделяю любовь АВК к стэйтфул,

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

IT>но раз уж он мне навесил ярлык стэйтлещика, то будем его носить гордо

Где это я на тебя ярлык навешивал? Просто ты очень часто проповедуешь стейтлес модель.

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

TK>>>Скажем так — это не цитирование, это просто демонстрация того, как можно теми-же словами написать про stateless.
AVK>>Фиговая демонстрация если честно, сплошное передергивание

TK>В чем передергивание?

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

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

Hello, "Геннадий Васильев"

> IT>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.
>
> Надо, но у тебя не размазано хранение состояния по двум максимально удалённым точкам — серверу БД и клиенту. Следовательно, есть возможность оптимизировать нагрузку на коммуникации. Следовательно, можно даже восстановить состояние клиента в полном объёме при обрыве/восстановлении связи "клиент-сервер", не привлекая к этому сервер БД.
>

Восстановить, не привлекая... В stateless такой проблемы даже в принципе быть не может...
Да и потом — что значит две максимально удаленных точки? База данных для хранения состояния это не самая удаленная точка. Да и потом — как на счет smart клиентов, работы в offline режиме? Вроде как все уже давно согласились с мнением, что коммуникации — это вещь не надежная. Сегодня связь с сервером есть, а завтра нужно поехать в командировку и ее уже нет (например в самолете). А в наше время — подобные простои это уже не позволительная роскошь.

>
> В сущности — да, и как раз клонирование появляется при размещении stateful-App-ядра (эк, термин-то

) на кластере. И клонирование действительно должно реализовываться вместе с синхронизацией, следовательно, его место — сугубо в ядре системы, где можно организовать выделенные связи между серверами, по которым не ездит клиентский трафик. И ещё отчасти поэтому появляется более строгое разделение функциональности клиента и сервера, следовательно — более стройная и удобная для модификаций система.

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

Posted via RSDN NNTP Server 1.8 beta

Hello, "Геннадий Васильев"

> TK>Ты можешь и сам прикинуть где такое может быть. Основной недостаток стайтфул модели — состояние приходится хранить в памяти на сервере. Если размер такого состояния велик начинаются траблы, кончается ресурсы сервера, память. конечно, IA64 и AMD64 как герои диснея "спешат на помощь", но это все только в краткосрочной перспективе.
>
> Ровно то же самое произойдёт с SQL-сервером. Как в том анекдоте: "Жить-то Win'95 на 4 мегабайтах будет, но и только".

Не совсем. Уже упомянутый Oracle 10g как раз предназначен для того, что-бы работать не на одном большом сервере, а на распределенном сообществе машин. Или тот-же google — вся система поиска является распределенной

> Ты очень и очень спешишь с обобщениями. Кроме того, хранение состояний в памяти это не "недостаток", как ты утверждаешь, а всего лишь черта stateful-модели. Недостатком оно становится в тех или иных случаях, не более того.
>

Скажем так — это плохая черта. А в некоторых случаях она может стать очень плохой.

> TK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий.
>
> Угумс. А ещё мы наблюдаем попытку впарить BizTalk.

>

Ладно BizTalk пока закроем

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

>
> TK>Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее:
> TK>никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода).
>
> Но никак не пример stateless-объекта.

Хотя да, такой метод может быть... например, статическим.

>

Ну это больше похоже на (всем уже здесь любимую) подмену понятий. Естественно, что в случае тех-же веб сервисов никакой речи о полноценных объектах не идет ?

> На самом деле вопрос несколько шире, чем просто хранение сотояний. Вопрос ещё и в методах обработки этих самых состояний. И кстати, тот ещё вопросик...
>

Вот именно.

> TK>А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта.
>
> Почти справедливое утверждение, но с одной маленькой поправкой — потому что нет серверов, реализующих полновесную и гибкую stateful-модель без существенных ритуальных плясок вокруг её реализации. Точно так же, как нет и достаточной наработанной базы подходов по этому поводу. Точно также, как есть заученное высказывание "зачем изобретать ещё один велосипед", правомерность применения которого нередко представляется очень спорной.

Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".
>

А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи?

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

Например списывание денег с дебетовых счетов. Компания MTC до сих пор не может отмазаться "воруют" и "куда делись мои деньги" — вот они последствия "обновления с задержкой". Хотя, идея интересная

Главное только не запускать, а то конкуренты глумиться начнут.

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

Так вот, использование stateful даже здесь позволит получить некоторый выигрыш.

Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу...
тут может пригодится и локальное хранилище данных и так-же то, что приложение уже само ориентировано на отправку более/менее законченных результатов.

> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то.

Причем, все это время, данные будут сидеть в памяти app сервера. В то время как, stateless сервер уже давно обслуживать новые запросы, а эти данные будут лежать в одной из баз данных на среднем уровне (причем несколько frontend серверов могут использовать эту базу одновременно — еще один дополнительный пункт в повышение общей надежности).

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

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

> Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.
>

SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает...

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

+1

> TK>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.
>
> Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.
>

Ну на счет дисковой подсистемы — это больше заблуждение. Всегда эффективнее держать кеш на локальном диске, чем доставать его по сети... Так-же кеш в оперативной памяти — хранение объектов в памяти это не оптимально. Да, это удобно для программиста — он освобождается от ненужных деталей и т.п. Но, с точки зрения эффективности — это совершенно не оптимально. Все эти отложенные загрузки, интеллектуальные кеши обеспечение конкуррентности своими руками производительности не прибавляют. С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям.

> Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД. Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется.

Конкретный App-сервер может ни шиша не знать о прикладной специфике.

>

"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения...

> TK>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции
>
> Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.
>

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

> TK>(все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные...
>
> А вот это, кстати, косвенно подтверждает тезис о снижении производительности OLTP в stateless-модели.

Второе аналогичное подтверждение состоит в том, что в тестах TPC-C MS использовала COM+ только для чтения данных, а обновление запускались через обычный ODBC. Что, в принципе, логично, если рассматривать stateless-модель в её естественной ипостаси — как удобной модели для трансформации представления данных.
>

Что значит чтение данных через COM+? Из SQL Server можно читать данные используя ODBC или OLE DB. COM+ это уже внешний сервис который к БД не так уж и много отношения имеет. Может они просто для записи в COM+ транзакции отключали?

>
> TK>И в итоге — стайтфул модель оказывается плохо масштабируемой. добавить просто так еще один сервер нельзя — нужно обеспечить согласованность внутренних кешей и т.п. остается — только наращивать производительность одной конкретной машины или вводить элементы stateless модели.
>
> Ухх... в итоге получается нечто, достойное рекламной статьи на сайте Microsoft, уж извини. Ты утверждаешь, что нельзя обеспечить согласование кэшей? А на основании чего ты так говоришь? Уж не основании ли того, что у тебя в распоряжении нету компонента "StatefulCacheSyncronizer"?

>

Я не спорю, можно обеспечить соглосование кешей, и прочих замечательных вещей. Возможно, что компоненту "StatefulCacheSyncronizer" можно купить в каком нибудь электронном магазине. Разговор о том, что насколько эффективно писать подобные компоненты в своем подразделении, или насколько велик бюджет проекта для покупких сервера (не только ПО, но и железо. Не будем забывать, что при увеличении производительности стоимость сервера растет не пропорционально) приложений с нужной функциональностью.

> TK>В противоположность ей стайтлесс модель на таких данных ведет себя хорошо, поскольку гибкие возможности современных быз ранных, обладающих большей информацией о механизмах хранения данных (все основано на серьезном математическом аппарате), эффективных средствах кеширования и распределения информации — не вносит практически никакого оверхеда, но предоставляет поистинне фантастические возможности для масштабирования. Редко меняющиеся данные спокойно могут реплицировать на десяток не особо мощных машин, и когда будут идти обращения к БД, они не будут испытывать практически никаких блокировок — поскольку вся архитектура является распределенной и выполнять эту работу будет наименее загруженный участник.
>
> 1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.

Надо ораклу с гуглом сказать

> 2. Оверхед таки вносится.
> 3. Математический аппарат в хинтах... ммм... это даже не смешно.

Хиты это больше прероготива апп серверов. Надо-же на чем-то производительность поднимать

> 4. Читается конечно, на одном дыхании, в этом не откажешь.

>

Распределенным может быть хранение данных.
1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер.
2. Редко изменяемые данные реплицируются на локальные базы ближе к frontend серверам. Учитывая, что репликация происходит только измененной информации — нагрузки будут минимальными. И практически мгновенное отображение изменений.

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

>

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

Posted via RSDN NNTP Server 1.8 beta

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

TK>>В чем передергивание?

AVK>В том что ты трактуешь мои высказывания как однозначную агитацию за стейтфул.

Андрей, мы не пытаемся друг другу что-то неприменно доказать, правильно? Мы просто беседуем. Зачем тогда эти инсинуации.

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

ГВ>Почти справедливое утверждение, но с одной маленькой поправкой — потому что нет серверов, реализующих полновесную и гибкую stateful-модель без существенных ритуальных плясок вокруг её реализации. Точно так же, как нет и достаточной наработанной базы подходов по этому поводу. Точно также, как есть заученное высказывание "зачем изобретать ещё один велосипед", правомерность применения которого нередко представляется очень спорной.

Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".

Но пока это "неверное" утверждение никто не опровергнул на практике.

ГВ>Здесь есть очень интересная деталь, про которую обычно принято забывать. Те же самые заказы, отгрузки прочая шелупонь прежде чем достичь места хранения сначала всегда создаются на одном из промежуточных или клиентском уровне. Исключение составляют случаи прямой связи клиента с сервером БД, но мы же не о них говорим, верно?

Так вот, использование stateful даже здесь позволит получить некоторый выигрыш. Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то. Опять-таки, можно, конечно, прокрутить ещё одну транзакцию в БД, она же у нас гибкая как змея и современная как космический корабль, но есть идея лучше: задержать накладную в памяти App-сервера на 180-300 секунд, тем самым освободив сервер БД от обязательных для него, но совершенно не нужных в контексте приложения транзакций. Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.

Вот видишь как ты всё невероятно усложняешь. Для стэйтлес всё описанное тобой сводится к следующему. Сервер создаёт, инициализирует объект и отдаёт его клиенту. В базу данных ничего не пишется. Клиент заполняет объект и либо отдаёт его серверу для сохранения в БД (здесь база данных действительно задействуется), либо нажимает escape и документ умирает без всякого обращения не то что к БД, но даже к серверу приложений. В крайнем случае придётся повозиться с номером накладной, если требования подразумевают его генерацию до заполнения документа.

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

Ну да. Только что ты нам это продемонстрировал

TK>>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.

ГВ>Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.

Для сложных отчётов нужно делать отдельный сервер и специально проектировать под это базу данных. Тот же OLAP предполагает недетское дублирование данных для эффективной работы и все нормальные формы вплоть до 2-й идут лесом.

TK>>А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша.

ГВ>Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД.

БД не надо вовлекать в то с чем она непосредственно не взаимодейтствует. Для этого пишутся агенты, которые могут работать по тем же принципам stateless. Т.е. взял данные, отдал данные. Либо получил данные, передал данные.

ГВ>Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется.

Конкретный App-сервер может ни шиша не знать о прикладной специфике.

Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?

TK>>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции

ГВ>Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.

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

ГВ>1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.

Это так в случае stateful

ГВ>2. Оверхед таки вносится.

Всегда.

ГВ>3. Математический аппарат в хинтах... ммм... это даже не смешно.

Не только в хинтах. Оптимизация запросов, кеширование, целостность и пр. В общем, всё то, что тебе так или иначе нужно будет переизобрести.

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

IT>>Аргумент отклоняется. Можно подумать, что в стэйтфул ничего гонять не надо.

AVK>Надо, но только параметры вызова, а не внутреннее состояние.

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

IT>>Возьми любой объект, живущий на сервере. Для обращения к его свойствам нужно сделать серверный вызов. Для обращения к одному и тому же свойству два раза, нужно сделать два вызова.

AVK>А зачем делать два вызова одного и того же?

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

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

Т.е. ты всё же клонируешь объект?

AVK>>>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи.

IT>>Было бы здорово, если бы ты привёл пример когда без этого не обойтись.

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

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

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

С ними всегда бяка. Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

IT>>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.

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

Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.

AVK>Кроме того серверу приложений нет необходимости быть универсальным, его как правило задачивают под узкий круг задач. Отсюда механика управления на сервере приложений более оптимальна. Оптимизацией запросов при помощи сервера приложений можно добится эффективности кеша на не очень часто меняемых данных в районе 99% и практически полного отсутствия блокировок в БД. Это результаты реальной системы. Сервер же БД в такой схеме периодически получает интенсивные и кратковременные плевки.

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

IT>>Ерунда.

AVK>Может и ерунда но именно так оно выходит на реальных серверах.

На разных реальных серверах обычно всё по разному.

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

AVK>Самой стейтлес блокировки не нужны, о том и речь. Вся тяжесть изоляции в этом случае ложится на сервер БД. А вот ему то как раз и приходится несладко.

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

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

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

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

AVK>Я не писал о задачках вроде нашего сайта. Я ж говорю что ты там совсем отвык от нашей действительности

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

IT>>И об этом нужно помнить всегда, даже когда имплементируешь то же самое обращение. В противовес в стэйтлес о потокоопасности можно практически забыть.

AVK>Пока не понадобится хранить состояния

.

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

AVK>Смею повторится — задачки бывают разные. Если данные по большей части быстро устаревают стетфул модель будет неэффективна, если наоборот неэффективной будеть стейтлес модель. Рулит, как всегда, помимо тактического ядерного заряда конечно, золотая серидина. Т.е. грамотное, с учетом предметной области, распределение между стейтфул и стейтлес, причем желательно без явной границы, т.е. чтобы каждый объект в определенной пропорции был и стейтлес и стейтфул.

Слова мужа

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

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

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

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

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

AVK>Не все так однозначно. Ровно так же резко усложняется проблема со стейтлес при больших нагрузках из-за лавинообразного нарастания блокировок в БД и ровно такой же геморой начинается при оптимизации этой самой БД и запросов к ней.

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

AVK>Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.

Возможно. Насочинять можно много чего.

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

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

IT>>Стэйтфул хорош для приложений с заранее детерминированной нагрузкой.

AVK>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.

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

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

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

AVK>>Извини за философию, но что то меня сегодня на конкретику не тянет

IT>Ok. Но все видели, это не я начал

Вот еще б статейку почитать какую-нить, чтоб лучше понимать суть спора...
А если б ее и еще кто-нить из вас написал...

Здравствуйте, Аноним, Вы писали:

А>Вот еще б статейку почитать какую-нить, чтоб лучше понимать суть спора...
А>А если б ее и еще кто-нить из вас написал...

А вообще-то идея неплохая...

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

ГВ>>[...] Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".
IT>Но пока это "неверное" утверждение никто не опровергнул на практике.

Ну, Игорь, чтобы такое утверждать, нужно как минимум владеть достаточно репрезентативной выборкой. Она у тебя есть?

ГВ>>Здесь есть очень интересная деталь, про которую обычно принято забывать. [skip детали, оставим только общее

]
IT>Вот видишь как ты всё невероятно усложняешь. Для стэйтлес всё описанное тобой сводится к следующему. Сервер создаёт, инициализирует объект и отдаёт его клиенту. В базу данных ничего не пишется. Клиент заполняет объект и либо отдаёт его серверу для сохранения в БД (здесь база данных действительно задействуется), либо нажимает escape и документ умирает без всякого обращения не то что к БД, ...

Дык итить в том-то и дело, что юзер удаляет/меняет документ почти сразу после того, как нажал Save, т.е., отправил его серверу.

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

Ну и получается катание туда-сюда полного состояния объекта. А если ещё учесть, что там справочники всяческие...

ГВ>>Правда, справедливости ради, следует заметить, что реализация такого подхода требует достаточной квалификации и самостоятельности программистов, что, увы, может стать проблемой в современных условиях.
IT>Ну да. Только что ты нам это продемонстрировал

Ну... я надеюсь.

TK>>>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.
ГВ>>Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.
IT>Для сложных отчётов нужно делать отдельный сервер и специально проектировать под это базу данных. Тот же OLAP предполагает недетское дублирование данных для эффективной работы и все нормальные формы вплоть до 2-й идут лесом.

Аналитика бывает разной и онлайновая в том числе. Как и отчёты. Кстати, часть онлайн-аналитики как раз и может выполнять App-сервер: данные-то все через него проходят.

TK>>>А почему? ведь в чистой стейтфул модели вся логика разруливания между клиентами ложится на один большой сервер, который делает вид, что обовсем знает, но как показывает практика, он и понятия не имеет о том, как можно эффективно управлять данными — единственная его заслуга — это побольше памяти для организации кеша.
ГВ>>Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД.
IT>БД не надо вовлекать в то с чем она непосредственно не взаимодейтствует. Для этого пишутся агенты, которые могут работать по тем же принципам stateless. Т.е. взял данные, отдал данные. Либо получил данные, передал данные.

Согласен.

ГВ>>Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется.

Конкретный App-сервер может ни шиша не знать о прикладной специфике.

IT>Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?

Да, конечно. Я имею ввиду критерии, по которым определяется, например:

— необходимость кеширования тех или иных данных;
— время задержки записи;
— распределение обработки между App-сервером и СУБД.

Справедливости ради — не очень удачно я выразился.

TK>>>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции
ГВ>>Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.
IT>БД обязана контролировать целостность данных. Если она этого не делает, то всегда найдётся какой-нибудь чудак на букву 'м', который запишет туда какой-нибудь бред. После этого твой сервер просто ляжет, если всецело полагается на целостность данных.

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

ГВ>>1. Вся архитектура не может быть распределённой, поскольку тогда её реализация будет заниматься только самосогласованием.
IT>Это так в случае stateful

Это так в случае распределенности где надо и не надо.

ГВ>>2. Оверхед таки вносится.
IT>Всегда.

Истинно так.

ГВ>>3. Математический аппарат в хинтах... ммм... это даже не смешно.
IT>Не только в хинтах. Оптимизация запросов, кеширование, целостность и пр. В общем, всё то, что тебе так или иначе нужно будет переизобрести.

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

хъ

IT>Андрей, мы не пытаемся друг другу что-то неприменно доказать, правильно? Мы просто беседуем. Зачем тогда эти инсинуации.

Уже не раз говорилось о том, что отдельные личности могут очень много принять на свой счет.

... << RSDN@Home 1.1.0 stable >>

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

AVK>>В том что ты трактуешь мои высказывания как однозначную агитацию за стейтфул.

IT>Андрей, мы не пытаемся друг другу что-то неприменно доказать, правильно? Мы просто беседуем.

Вот и я о том же. И непонятно зачем было мои слова при этом выворачивать наизнанку.

IT>Зачем тогда эти инсинуации.

Вот и мне хотелось бы знать. Неужели нельзя было сказать тоже самое в менее издевательской манере?

... << RSDN@Home 1.1.2 beta 1 >>

Hello, "AndrewVK"

> IT>Зачем тогда эти инсинуации.
> Вот и мне хотелось бы знать. Неужели нельзя было сказать тоже самое в менее издевательской манере?

Никто над тобой не издевался. Просто относись к этому с большим чувством юмора

Posted via RSDN NNTP Server 1.6

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

хъ

ГВ>Дык итить в том-то и дело, что юзер удаляет/меняет документ почти сразу после того, как нажал Save, т.е., отправил его серверу.

Как уже правильно тут говорили, важно не смещать акценты от одного к другому и использовать по-возможности, оба подхода. В частности, в твоем случае, сделать кеш на стейтлесс модели намного проще (rowversion). Т.е. алгоритм несколько усложняется:
1. Сервер смотрит в кеше объект и по rowversion проверяет насколько он соответствует дейтсивтельному состоянию объекта в БД. Если все ок, го то 3.
2. Сервер создаёт, инициализирует объект и
3. отдаёт его клиенту...

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

ГВ>Ну и получается катание туда-сюда полного состояния объекта. А если ещё учесть, что там справочники всяческие...

Катание куда?

хъ

IT>>Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?

ГВ>Да, конечно. Я имею ввиду критерии, по которым определяется, например:

ГВ>- необходимость кеширования тех или иных данных;

Это не зависит от модели сохранения состояния.

ГВ>- время задержки записи;

Отложенная запись? Ну не знаю...

ГВ>- распределение обработки между App-сервером и СУБД.

Как-то слишком абстрактно.

хъ

ГВ>Ну... чудак на эту самую букву вполне может и триггеры с констрэйнтами похерить, если у него админские права есть.

А это уже административные проблемы.

ГВ>Противостоять всем чудакам никакя софтина не сможет. Потом, определяет правила целостности всё-таки приложение, одной из подсистем которого как раз и является БД.

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

... << RSDN@Home 1.1.0 stable >>

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

AVK>>Надо, но только параметры вызова, а не внутреннее состояние.

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

А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП. Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.
Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.

Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?

AVK>>А зачем делать два вызова одного и того же?

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

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

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

IT>Т.е. ты всё же клонируешь объект?

В бизнес-коде нет, на клиента во многих случаях да.

IT>Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

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

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

IT>С ними всегда бяка.

Тем не менее в стейтфул модели бяка поменьше.

IT>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

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

IT>Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.

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

IT>Чудес не бывает. Снимая нагрузку с сервера БД ты её просто переносишь на сервер приложений, вот и всё.

Безусловно.

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

Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.

AVK>>Может и ерунда но именно так оно выходит на реальных серверах.

IT>На разных реальных серверах обычно всё по разному.

Разумеется. Потому я особо оговорился — речь идет об управлении предприятием. Т.е. наш сайт под это уже не попадает.

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

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

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

Хороши усилия — после каждого запроса скидывать состояние в БД

IT>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию

, давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.

Зря.

IT> Что там управление предприятиями, что тут,

Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.

IT>что там лоскутная автоматизация никого не устраивает, что здесь. Тем не менее все латали, латают и будут латать.

В России чаще всего и латать то нечего. Либо автоматизации нет совсем, либо она на примитивном уровне самопальных однопользовательских программулек. Лет через 15-20 у нас наверное и законы устаканяться и на каждом предприятии будут легаси-системы, но это все нескоро.

IT>Слова мужа

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

Слова Стива Шварца помнишь?

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

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

Отстал от жизни

Увлечение веб интерфейсами начинает имхо потихонечку спадать. Теперича, опять же помимо тактического ядерного заряда, рулит XAML, который не пойми что

AVK>>Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.

IT>Возможно. Насочинять можно много чего.

Ну он вроде как говорил где именно та или иная схемка реализована на практике.

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

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

Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе. Кроме того не следует пытаться надуть муху до размеров слона. Если начинали с решения для малых предприятий пытаться потом получить из этого кластерного монстра неразумно.

AVK>>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.

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

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

... << RSDN@Home 1.1.2 beta 1 >>

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

ГВ>>Ну... чудак на эту самую букву вполне может и триггеры с констрэйнтами похерить, если у него админские права есть.

AS>А это уже административные проблемы.

Точно так же предоставление прав доступа к серверу БД не только серверу приложений но и всяким чудакам тоже административная проблема.

AS>Понятное дело, что бизнес-логика должна что-то валидейтить, но проверять на уникальность поле или группу полей и соблюдать ссылочную целостность на сервере приложений — как бы по мягче выразиться, просто глупо и неэффективно.

Это ты зря. Не все можно провалидировать в sql сервере, тем более не все можно провалидировать там эффективно. Юкон правда позволяет эту задачку таки решить.

... << RSDN@Home 1.1.2 beta 1 >>

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

TK>Никто над тобой не издевался. Просто относись к этому с большим чувством юмора

Наверное, но я в данном случае не смог.

... << RSDN@Home 1.1.2 beta 2 >>

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

хъ

AVK>Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.

Не вижу проблем (если база верно спроектирована). У меня как раз такая ситуация и я прекрасно обхожусь стейтлесс моделью.

хъ

AVK>У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.

Дык это стейтфул управляет всей тяжестью состояний, а не стейтлес! О потом, я вот уже много раз слышал про тяжесть отката, но никак не могу понять, в чем она выражается?

хъ

IT>>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

AVK>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

Блин! Ты хочешь сказать, что в стейтфул модели проблемы перекладываються на машину и она код лабает? Что ты подрузомеваешь под проблемами? Реализация бизнес-логики всегда лежит на программере, а вот реализация правил ссылочной целостности — нет.

хъ

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

А можно по подробнее на счет этой оптимизации. Оптимизацию SQL сервера я знаю, оптимизацию софта тоже, но оптимизацию логики на основе метаданных...

хъ

AVK>Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.

А именно?

хъ

AVK>Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.

Зато данные гарантированно находятся в согласованном и устойчивом состоянии. А что произойдет с твоим аппсервером, если отрубится питание — сказать сложно.

хъ

AVK>Хороши усилия — после каждого запроса скидывать состояние в БД

Не обязательно. Кеш еще никто не отменял.

хъ

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

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

С помощью железа можно расшарять до бесконечности.

AVK>Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

А что, изолирование локиги является отличительной чертой только стейтфул модели? И потом, зачем загонять SQL-сервер в кластер, если у тебя все лопатиться вне его.

... << RSDN@Home 1.1.0 stable >>

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

хъ

AVK>Это ты зря. Не все можно провалидировать в sql сервере, тем более не все можно провалидировать там эффективно.

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

AVK> Юкон правда позволяет эту задачку таки решить.

Если ты на счет триггеров, то они всегда являлись "последним средством". И то, что они теперь будут доступны в манажд режиме — мало что меняет.

... << RSDN@Home 1.1.0 stable >>

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

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

Фигня. В современных приложениях большинство интересующих нас ограничений целостности невыразимы в декларативных терминах СУБД. Исторически триггеры, и прочие сторед процедуры вводились не в последнюю очередь для обхода этих декларативных ограничений и поддержки процедурной функциональности.
В N-tier архитектуре все процедурные аспекты лучше перемещать на сторону апп-сервера, для better maintainability. А вот декларативные аспекты надо всенепременно на уровне storage оставлять. Не столько для того, чтобы проверить целостность всякую, а для semantic query optimization. По любому, генерацию уникального номера документа в соответствии с правилами, принятыми в компании, должен выполнять app-server еще до обращения к базе. В свете этого введение unique constraint на уровне RDBMS кажется избыточным, но на практике его наличие означает немедленный хинт оптимизатору, что селективность запроса на точное совпадение по данному полю максимальна. А вот процедурные правила ничего серверу не дают.

Защита от прямого доступа к базе должна все же осуществляться более цивилизованными методами. Дали ручки у апп-сервера подергать — и дергайте. А в n-tier приложении руками в базу лазить — это спорт для экстремалов.

... << RSDN@Home 1.1.0 stable >>

Hello, "AndrewVK"

> IT>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.
>
> А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.

С каких это пор — получение объекта целиком это не ООП? Объектность как таковая не зависит от того, в каком месте находятся данные.

> Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.

Замечательно. Эти документы порождаются в какой-то БД и там остаются.

> Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.
>

Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные, и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.

> Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?
>

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

>
> У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.
>

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

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

А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

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

Не обязательно. Главное это создание устойчивой инфраструктуры — тогда бизнес программист просто не будет задумываться об этом. Хотя, да. в короткой перспективе stateful это удобно.

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

Тоже самое и в stateful. Необходимость постоянно держать состояние в app сервере увеличивает суммарную на него нагрузку и размазывает ее по времени. Только в случае со stateless проще переложить часть нагрузки на клиента / другой сервер.

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

>

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

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

>
> Отстал от жизни

>

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

> IT>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.
>
> Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.

Posted via RSDN NNTP Server 1.6

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

AVK>Это ты зря. Не все можно провалидировать в sql сервере, тем более не все можно провалидировать там эффективно. Юкон правда позволяет эту задачку таки решить.
Так юкон — это собственно попытка внести полноценный app-server внутрь db-server. Для обеспечения максимальной производительности.
В общем, я сейчас их концепцию себе примерно так представляю, что миддл-таер режется напополам; та часть логики, которая ближе к представлению (ну там отчеты всякие, статическая валидация данных) живет в контексте IIS, а та часть логики, которая ближе собственно к уровню данных — живет в контексте MSSQL. Собственно говоря, маус клик путешествует примерно таким образом:

transport|               | HTTP   |   |SOAP  |          |OLE DB |                          
media    | (HTML/JScript)|------->|ASP|----->|WebService|------>|(SQL/.NET Procedural code)
context  |       IE      |        |IIS|      |   IIS    |       |       Yukon

Возможно, я просто еще не вьехал в их service-oriented architecture.

... << RSDN@Home 1.1.0 stable >>

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

AS>Если ты на счет триггеров, то они всегда являлись "последним средством". И то, что они теперь будут доступны в манажд режиме — мало что меняет.

Да нет, меняет много. Теперь можно делать куда более сложные проверки. Более того можно эти проверки продублировать на клиенте, не переписывая код проверок.

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>Отложенная запись — это очень опасная операция. Любой сбой, любая потеря данных — все это может серьезно подорвать доверие к такой системе. Данные нужно хранить в месте которе более устойчиво, чем оперативная память (прочь соблазны).
Дело не в доверии. Дело в ACID. Отложенные записи — прямая дорога в ад. Мы не имеем права отказываться от committed транзакций. Сколько бы уровней ни было, OLTP система обязана убедиться в том, что durability достигнута прежде, чем отрапортовать об окончании транзакции. Точка. В некоторых особо редких случаях это не так важно, но это уже не OLTP система, а что-то другое.

... << RSDN@Home 1.1.0 stable >>

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

AS>Не вижу проблем (если база верно спроектирована). У меня как раз такая ситуация и я прекрасно обхожусь стейтлесс моделью.

Как?

AVK>>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

AS>Блин! Ты хочешь сказать, что в стейтфул модели проблемы перекладываються на машину и она код лабает?

На сервер приложений.

AS> Что ты подрузомеваешь под проблемами? Реализация бизнес-логики всегда лежит на программере, а вот реализация правил ссылочной целостности — нет.

Я не про бизнес логику, а про управление состояниями.

AS>А можно по подробнее на счет этой оптимизации. Оптимизацию SQL сервера я знаю, оптимизацию софта тоже, но оптимизацию логики на основе метаданных...

Оптимизацию управления состояниями. Про логику я нигде не писал.

AVK>>Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.

AS>Зато данные гарантированно находятся в согласованном и устойчивом состоянии. А что произойдет с твоим аппсервером, если отрубится питание — сказать сложно.

Смотря с каким. Чаще всего просто откатится текущая транзакция, у него, в отличие от сервера БД, транзакции в памяти.

AVK>>Хороши усилия — после каждого запроса скидывать состояние в БД

AS>Не обязательно. Кеш еще никто не отменял.

Кеш записи? Не всегда это допустимо.

AS>А что, изолирование локиги является отличительной чертой только стейтфул модели?

Нет, но в стейтфул модели это достигается проще.

AS> И потом, зачем загонять SQL-сервер в кластер, если у тебя все лопатиться вне его.

Во-первых про все никто не говорил, во-вторых не всегда узким местом являются вычислительные алгоритмы.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>Дык итить в том-то и дело, что юзер удаляет/меняет документ почти сразу после того, как нажал Save, т.е., отправил его серверу.
AS>Как уже правильно тут говорили, важно не смещать акценты от одного к другому и использовать по-возможности, оба подхода. В частности, в твоем случае, сделать кеш на стейтлесс модели намного проще (rowversion). Т.е. алгоритм несколько усложняется:
AS>1. Сервер смотрит в кеше объект и по rowversion проверяет насколько он соответствует дейтсивтельному состоянию объекта в БД. Если все ок, го то 3.
AS>2. Сервер создаёт, инициализирует объект и
AS>3. отдаёт его клиенту...

Всё это так, да, но при чём тут кэш?

Речь шла о том, что мы избавляем SQL-сервер от лишних транзакций.

IT>>>...но даже к серверу приложений. В крайнем случае придётся повозиться с номером накладной, если требования подразумевают его генерацию до заполнения документа.
ГВ>>Ну и получается катание туда-сюда полного состояния объекта. А если ещё учесть, что там справочники всяческие...

AS>Катание куда?

Тело объекта в варианте Игоря проходит таким маршрутом:

Создание: App-сервер -> клиент -> App-сервер -> SQL-сервер (транзакция).

Редактирование: [SQL-сервер? -> ] App-сервер -> клиент -> App-сервер -> SQL-сервер (транзакция).

В приведённом мной примере получается следующее, даже если для удобства сравнения допустить, что тело объекта перемещается на клиента:

Создание: App-сервер -> клиент -> App-сервер -> буфер отложенных транзакций, транзакция T1

Редактирование: App-сервер -> клиент -> App-сервер -> буфер отложенных транзакций, транзакция T1 удаляется не дойдя до SQL-сервера, вместо неё создаётся T2.

То есть, SQL-сервер вместо двух транзакций выполняет одну.

IT>>>Что такое по твоему "эффективность управления данными"? Можно этот термин представить немножко более развёрнуто?
ГВ>>Да, конечно. Я имею ввиду критерии, по которым определяется, например:
ГВ>>- необходимость кеширования тех или иных данных;
AS>Это не зависит от модели сохранения состояния.

Да, в принципе не зависит.

ГВ>>- время задержки записи;
AS>Отложенная запись? Ну не знаю...

ГВ>>- распределение обработки между App-сервером и СУБД.
AS>Как-то слишком абстрактно.

Естественно, что не вся обработка в полном объёме ложится на App-сервер, это просто неразумно. Например, такие вычисления, как подсчёт суммы строк накладных или средней температуры по отдельно взятой палате

, прекрасно им выполняются самостятельно, а вот подсчёт суммы всех накладных за месяц равно как и средней температуры всех, поступивших на третий день после её подъёма

обычно лучше переложить на СУБД.

Однако, всегда есть скользкие моменты: например, накладная (дались же они мне

) состоит из 200 строк, а в памяти App-сервера в данный момент их нет. Вопрос, что делать? Собственно, вариантов выбора два: а) грузить всё в память и вычислять сумму и б) отдать это в шаловливые ручки SQL-сервера. Выбор производится в динамике — на основании сравнения оценки стоимости чтения 200 строк и стоимости вычисления суммы средствами БД. Выбираем самый дешёвый вариант и выполняем его. Роль App-сервера в данном случае состоит в выборе оптимального решения по предложенным ему характеристикам.

В реальности конечно, всё намного сложнее, но принцип вот таков.

AS>хъ

ГВ>>Ну... чудак на эту самую букву вполне может и триггеры с констрэйнтами похерить, если у него админские права есть.
AS>А это уже административные проблемы.

Конечно.

Поэтому и решаются они отнюдь не изменением архитектуры сервера.

ГВ>>Противостоять всем чудакам никакя софтина не сможет. Потом, определяет правила целостности всё-таки приложение, одной из подсистем которого как раз и является БД.

AS>Понятное дело, что бизнес-логика должна что-то валидейтить, но проверять на уникальность поле или группу полей и соблюдать ссылочную целостность на сервере приложений — как бы по мягче выразиться, просто глупо и неэффективно.

В каких-то случаях — да, в каких-то — нет. Не стоит обобщать.

Попробуй для начала сравнить время выполнения поиска в std::map<...> со скоростью проверки констрайнта UNIQUE на сопоставимых объёмах данных. И не забудь ещё, что в случае нарушения констрайнта у тебя ответ пойдёт через всю прослойку от SQL-сервера до App-сервера.

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

S>Так юкон — это собственно попытка внести полноценный app-server внутрь db-server. Для обеспечения максимальной производительности.

Не, сам МС говорит что юкон не предназначен для работы в качестве сервера приложений. Они рекомендуют втащить DAL внутрь, а вот рабочую бизнес-логику оставлять в мидлтаер. Т.е. фактически подзаточить сервер БД под оптимальный для задачки интерфейс, дабы не таскать между процессами лишнее.

S>В общем, я сейчас их концепцию себе примерно так представляю, что миддл-таер режется напополам; та часть логики, которая ближе к представлению (ну там отчеты всякие, статическая валидация данных) живет в контексте IIS, а та часть логики, которая ближе собственно к уровню данных — живет в контексте MSSQL.

Примерно так. Только какой это тогда полноценный сервер приложений?

S>Возможно, я просто еще не вьехал в их service-oriented architecture.

А это уже из другой области, из области индиго. У индиго свой хост (ServerEnvironment) и свои особенности. Понятно что это уже сервер приложений в чистом виде.

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>С каких это пор — получение объекта целиком это не ООП?

С таких что вобще чистый стейтлес это никакая не ООП.

TK>Объектность как таковая не зависит от того, в каком месте находятся данные.

Объект предполагает состояние, иначе это не объект, а набор процедур. Если у серверного объекта нет состояния (читай стейтлес модель) то нет и никакого ООП.

>> Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.

TK>Замечательно. Эти документы порождаются в какой-то БД и там остаются.

То есть на все время редактирования создавать транзакцию в сервере БД?

TK>Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные,

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

TK>и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.

А, то есть заводим две БД — одну основную, другую на редактирование. И к чему весь этот оверхед по гонянию состояний по диску, если можно все оставить в памяти? Если жалко памяти стейтфул сервер приложений тоже может поскидывать лог транзакции в БД, но только делать он это будет лишь при необходимости (транзакция подзатянулась) а не всегда, даже если в транзакции всего пара объектов поменялась.

>> Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?
>>

TK>Вести лог соединений. При отправке пакета сообщений ему присваивается уникальный номер. После этого клиенту остается только проверять — в каком состоянии находится обработка данного пакета.

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

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

В данном конкретном случае совсем не очевидный плюс, скорее минус.

TK>Бизнес код это логика, работы и к сосотоянию она имеет очень мало отношения.

См. выше

TK> И, если посмотреть на развитие индустрии ПО — именно к этому все и движется. Smart приложения набирают все большую популярность — даже возможности сегодняшней ноты могут превосхидить недавние сервера, не говоря уже о десктоп системах. В этой ситуации использование stateless технологий упрощает создание распределенных приложений.

Что то ты последнее время постоянно на маркетинговые лозунги срываешься

.

TK>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

А зачем на каждом шаге?

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

TK>Тоже самое и в stateful. Необходимость постоянно держать состояние в app сервере увеличивает суммарную на него нагрузку и размазывает ее по времени.

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

TK>XAML это типичный пример дальнейшего развития веб интерфейса.

Можно точно так же сказать что это типичный пример дальнейшего развития GUI-архитектуры аля свинг. На самом деле это слияние обоих технологий.

TK>В этой ситуации появление XAML, как своеобразного гибрида веб технологий и возможностей .NET выглядит очень естественным продолжением.

При чем здесь возможности нета? Гибрид, да, но не возможностей нета, а архитектур ООП GUI и веб-приложений. Например ключевое отличие GUI десктопного от вебовского — наличие состояния в одном месте. В XAML состояние где?

TK>Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.

На самом деле это от модели не зависит. Вот тот пример со стейтфул моделью, ограниченной рамками транзакции точно так же спокойно распараллеливается.

... << RSDN@Home 1.1.2 beta 2 >>

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

хъ

Ну почти все верно, только asp.net может сразу дернуть за апп-сервер. Не нужно никаких SOAP и прочих тормозов.

... << RSDN@Home 1.1.0 stable >>

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

хъ

ГВ>В каких-то случаях — да, в каких-то — нет. Не стоит обобщать.

Попробуй для начала сравнить время выполнения поиска в std::map<...> со скоростью проверки констрайнта UNIQUE на сопоставимых объёмах данных.

А если ключ составной? Зачем изобретать велосипед?

ГВ>И не забудь ещё, что в случае нарушения констрайнта у тебя ответ пойдёт через всю прослойку от SQL-сервера до App-сервера.

Ну и что? Я уж лучше доверюсь в шаловливые ручки SQL-сервера, чем в на коленках написанный рукоблудный апп-сервер.

... << RSDN@Home 1.1.0 stable >>

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

хъ

S>Фигня. В современных приложениях большинство интересующих нас ограничений целостности невыразимы в декларативных терминах СУБД. Исторически триггеры, и прочие сторед процедуры вводились не в последнюю очередь для обхода этих декларативных ограничений и поддержки процедурной функциональности.

Не согласен. Или поясни более подробно, что ты имел в виду под процедурной функциональностью.

S>В N-tier архитектуре все процедурные аспекты лучше перемещать на сторону апп-сервера, для better maintainability. А вот декларативные аспекты надо всенепременно на уровне storage оставлять. Не столько для того, чтобы проверить целостность всякую, а для semantic query optimization. По любому, генерацию уникального номера документа в соответствии с правилами, принятыми в компании, должен выполнять app-server еще до обращения к базе.

Зачмечательно. Только вот когда ты будешь делать кластер, ты поимеешь серьезные проблемы от синхронизации апп-серверов.

S>В свете этого введение unique constraint на уровне RDBMS кажется избыточным, но на практике его наличие означает немедленный хинт оптимизатору, что селективность запроса на точное совпадение по данному полю максимальна. А вот процедурные правила ничего серверу не дают.

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

S>Защита от прямого доступа к базе должна все же осуществляться более цивилизованными методами. Дали ручки у апп-сервера подергать — и дергайте. А в n-tier приложении руками в базу лазить — это спорт для экстремалов.

Про разделение на слои пока речь не идет.

Я за SQL-сервер как средство долговременного хранения бизнес-информации и как средство эффективной работы с ними. Пусть хоть 1000 запросов в секунду придется ему выдерживать.
Городить огород из собственных наработок в таком уском месте — потеря времени и сил. Путь даже в некоторых случаях это может и привести к росту производительности.

... << RSDN@Home 1.1.0 stable >>

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

TK>>С каких это пор — получение объекта целиком это не ООП?
AVK>С таких что вобще чистый стейтлес это никакая не ООП.

Но, это не значит, что стейтлесс метод не может вернуть объект.

TK>>Объектность как таковая не зависит от того, в каком месте находятся данные.

AVK>Объект предполагает состояние, иначе это не объект, а набор процедур. Если у серверного объекта нет состояния (читай стейтлес модель) то нет и никакого ООП.

Есть набор операций над объектами.

>>> Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.

TK>>Замечательно. Эти документы порождаются в какой-то БД и там остаются.
AVK>То есть на все время редактирования создавать транзакцию в сервере БД?

Что за бред?

TK>>Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные,
AVK>Какие проведенные? Это уже бизнес логика, мы же говорим о механике сервера приложений. Впрочем это я и стремлюсь показать — управление средой в стейтлес модели усиленно мигрирует в бизнес-логику.

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

TK>>и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.

AVK>А, то есть заводим две БД — одну основную, другую на редактирование. И к чему весь этот оверхед по гонянию состояний по диску, если можно все оставить в памяти?

Кто сказал, что база не может быть в памяти? в рамках того-же COM+ был проект IMDB. Смотри дальше — база это абстрактное хранилище. А рельным его делают конкретные интерфейсы.

AVK>Если жалко памяти стейтфул сервер приложений тоже может поскидывать лог транзакции в БД, но только делать он это будет лишь при необходимости (транзакция подзатянулась) а не всегда, даже если в транзакции всего пара объектов поменялась.

т.е. будет пример создания long running транзакции своими руками? Не очередной ли это statefull велосипед?

AVK>Замечательная демонстрация моих слов — логика управления процессом вычисления попала в бизнес-логику.

В любом случае — наличие логики это лучше чем ее отсутсвие (что замерательно демонстрируют твои дубли в .NET форуме сегодня)

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

AVK>В данном конкретном случае совсем не очевидный плюс, скорее минус.

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

TK>>Бизнес код это логика, работы и к сосотоянию она имеет очень мало отношения.

AVK>См. выше

Это ты про отсутствие логики?

TK>> И, если посмотреть на развитие индустрии ПО — именно к этому все и движется. Smart приложения набирают все большую популярность — даже возможности сегодняшней ноты могут превосхидить недавние сервера, не говоря уже о десктоп системах. В этой ситуации использование stateless технологий упрощает создание распределенных приложений.

AVK>Что то ты последнее время постоянно на маркетинговые лозунги срываешься

Какие лозунги? кроме biztalk я тут буольше ничего не упоминал

TK>>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

AVK>А зачем на каждом шаге?

т.е. ты предлагаешь возложить на бизнес програмиста логику управления процессом?

TK>>Тоже самое и в stateful. Необходимость постоянно держать состояние в app сервере увеличивает суммарную на него нагрузку и размазывает ее по времени.

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

Да, ему нужно следить за актальностью кеша, изменений в бизнес объектах, обслуживать кучу одновременных клиентов наконец...

TK>>В этой ситуации появление XAML, как своеобразного гибрида веб технологий и возможностей .NET выглядит очень естественным продолжением.

AVK>При чем здесь возможности нета? Гибрид, да, но не возможностей нета, а архитектур ООП GUI и веб-приложений. Например ключевое отличие GUI десктопного от вебовского — наличие состояния в одном месте. В XAML состояние где?

В десктопном приложении состояние где? а в вебовском? ты так легко можешь провести черту?

TK>>Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.

AVK>На самом деле это от модели не зависит. Вот тот пример со стейтфул моделью, ограниченной рамками транзакции точно так же спокойно распараллеливается.

стайтфул модель ограниченная рамками одной транзакции — это практически тот-же stateless — когда время жизни минимально, либо это практически не жилец под большой нагрузкой.

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

TK>Но, это не значит, что стейтлесс метод не может вернуть объект.

Объект? Не может. Он может вернуть только кусок данных, которые может поднять объект которые есть у тебя.

AVK>>Объект предполагает состояние, иначе это не объект, а набор процедур. Если у серверного объекта нет состояния (читай стейтлес модель) то нет и никакого ООП.

TK>Есть набор операций над объектами.

Набор операций над данными. Клиенту по барабану что там внутри объекты. Для клиента стейтлес сервер выглядит просто набором процедур, не более того.

TK>>>Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные,
AVK>>Какие проведенные? Это уже бизнес логика, мы же говорим о механике сервера приложений. Впрочем это я и стремлюсь показать — управление средой в стейтлес модели усиленно мигрирует в бизнес-логику.

TK>Бизнес логику говоришь... Раз уж ты завел разговор о порождении, то следуя твоим словам можно предположить, что в statefull архитектуре порожденные документы появляются без всякой логики?

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

AVK>>А, то есть заводим две БД — одну основную, другую на редактирование. И к чему весь этот оверхед по гонянию состояний по диску, если можно все оставить в памяти?

TK>Кто сказал, что база не может быть в памяти? в рамках того-же COM+ был проект IMDB.

Я в курсе.

TK>Смотри дальше — база это абстрактное хранилище. А рельным его делают конкретные интерфейсы.

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

TK>т.е. будет пример создания long running транзакции своими руками?

Так их в любом случае нужно руками создавать, если не привлекать сторонние решения вроде бизтолка. sql сервера, к несчастью, их обычно не умеют.

AVK>>Замечательная демонстрация моих слов — логика управления процессом вычисления попала в бизнес-логику.

TK>В любом случае — наличие логики это лучше чем ее отсутсвие (что замерательно демонстрируют твои дубли в .NET форуме сегодня)

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

AVK>>В данном конкретном случае совсем не очевидный плюс, скорее минус.

TK>Смотри глубже. использование конвейера позволяет решить большинство долгосрочных целей.

Не надо там глубже, там надо вполне определенный функционал.

TK>>> И, если посмотреть на развитие индустрии ПО — именно к этому все и движется. Smart приложения набирают все большую популярность — даже возможности сегодняшней ноты могут превосхидить недавние сервера, не говоря уже о десктоп системах. В этой ситуации использование stateless технологий упрощает создание распределенных приложений.

AVK>>Что то ты последнее время постоянно на маркетинговые лозунги срываешься

TK>Какие лозунги? кроме biztalk я тут буольше ничего не упоминал

Ну а как же SOA, GRID, smart приложения?

TK>>>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

AVK>>А зачем на каждом шаге?

TK>т.е. ты предлагаешь возложить на бизнес програмиста логику управления процессом?

Нет, предлагаю возложить на сервер приложений.

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

TK>Да, ему нужно следить за актальностью кеша,

Если он есть. Впрочем как точно так же нужно следить и стейтлес варианту.

AVK>>При чем здесь возможности нета? Гибрид, да, но не возможностей нета, а архитектур ООП GUI и веб-приложений. Например ключевое отличие GUI десктопного от вебовского — наличие состояния в одном месте. В XAML состояние где?

TK>В десктопном приложении состояние где? а в вебовском? ты так легко можешь провести черту?

Я как раз не могу, это ты почему то утверждаешь что xaml мигрировал из веба.

TK>стайтфул модель ограниченная рамками одной транзакции — это практически тот-же stateless

А если добавить long-running транзакции?

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

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>Смотря с каким. Чаще всего просто откатится текущая транзакция, у него, в отличие от сервера БД, транзакции в памяти.

То есть? Транзакция рано или поздно должна сказать commit и после этого она не имеет права откатиться. А если она в памяти, то все, баста карапузики.
Если же ты при commit сохраняешь-таки ее в БД, то непонятно в чем преимущество..

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

AVK>>Смотря с каким. Чаще всего просто откатится текущая транзакция, у него, в отличие от сервера БД, транзакции в памяти.

M>То есть? Транзакция рано или поздно должна сказать commit и после этого она не имеет права откатиться.

А после этого прежде чем что то поменять нужно начать новую.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>Объект? Не может. Он может вернуть только кусок данных, которые может поднять объект которые есть у тебя.

Любая программная сущность это кусок данных. Все зависит от того, как с ней работать.

TK>>Есть набор операций над объектами.

AVK>Набор операций над данными. Клиенту по барабану что там внутри объекты. Для клиента стейтлес сервер выглядит просто набором процедур, не более того.

Не поверишь, но большинство из объектов описывают данные. тоже самое — процедуры, методы. Это просто терминология, а если капнуть чуть глубже, и посмотрим на любой метод, то что мы увидим — обычная процедура, просто первым параметром (обычно скрытым) передается кусок данных. Является ли скрытость параметра признаком настоящего объекта? думаю, что нет. А следовательно что есть такое stateless метод? Это тот-же объект только опредставляется он средствами отличными от того, как представляются объекты в памяти.

TK>>Бизнес логику говоришь... Раз уж ты завел разговор о порождении, то следуя твоим словам можно предположить, что в statefull архитектуре порожденные документы появляются без всякой логики?

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

В случае со stateless этим управлением занимается хранилище данных. В остальном-же затачивать бизнес логику так-же не обязательно.

TK>>Смотри дальше — база это абстрактное хранилище. А рельным его делают конкретные интерфейсы.

AVK>Ну то есть в итоге получается тот же стейтфул сервер приложений, тока обозванный по другому. Что и требовалось доказать

Ну, мы-же тут ничего друг другу не доказываем. Просто рассуждение на тему применимости различных подходов проектирования.

TK>>т.е. будет пример создания long running транзакции своими руками?

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

Почему-же есть Workflow Services for SQL Server — часть функциональности можно взять оттуда.

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

Называется выкрутился

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

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

В любом случае — даже существующий работает плохо.

TK>>>>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.
AVK>>>А зачем на каждом шаге?

А кто будет принимать решение относительно каждого шага?

TK>>т.е. ты предлагаешь возложить на бизнес програмиста логику управления процессом?
AVK>Нет, предлагаю возложить на сервер приложений.

В случае с stateless эта логика так-же не на программисте.

AVK>Если он есть. Впрочем как точно так же нужно следить и стейтлес варианту.

Ну, тупое следование до добра не доведет...

TK>>В десктопном приложении состояние где? а в вебовском? ты так легко можешь провести черту?
AVK>Я как раз не могу, это ты почему то утверждаешь что xaml мигрировал из веба.

Не из свинга-же

если следовать ms технологиям — это дальнейшее развитие IE.

TK>>стайтфул модель ограниченная рамками одной транзакции — это практически тот-же stateless

AVK>Я о том и говорю что не стоит себя ограничивать рамками одной модели.

С хранением состояния никто не спорит. основной вопрос — как к этому подходить.

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

AVK>>Объект? Не может. Он может вернуть только кусок данных, которые может поднять объект которые есть у тебя.

TK>Любая программная сущность это кусок данных.

+ кусок кода.

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

Не надо рассказывать прописные истины, это и так давно известно. Речь о другом — чем то ведь ООП от процедурного программирования отличается? Никто не спорит с тем что на основе веб сервисов тех же можно построить ООП механику, как впрочем и писать ООП программы на чисто процедурном языке. Но точно так же это вызывает определенный программный оверхед на ручную реализацию той же механики. Отсюда тот вывод, который я неоднократно уже писал — написание бизнес-кода усложняется.

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

TK>Почему-же есть Workflow Services for SQL Server — часть функциональности можно взять оттуда.

И получим тот самый стейтфул сервер приложений. От того что решения предоставляет МС они не становятся стейтлес.

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

TK>Называется выкрутился

Ну ак как ты думал

TK>А демонстрирует это то, что statefull и stateless подходы несколько различаются и переносить реализацию в слепую нельзя — черевато подобными ошибками.

А кто там чего переносил? Оно изначально проектировалось именно в стейтлес модели.

TK>>>т.е. ты предлагаешь возложить на бизнес програмиста логику управления процессом?
AVK>>Нет, предлагаю возложить на сервер приложений.

TK>В случае с stateless эта логика так-же не на программисте.

Ага, на вспомогательном стейтфул сервере.

AVK>>Я как раз не могу, это ты почему то утверждаешь что xaml мигрировал из веба.

TK>Не из свинга-же

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

AVK>>Я о том и говорю что не стоит себя ограничивать рамками одной модели.

TK>С хранением состояния никто не спорит. основной вопрос — как к этому подходить.

Ну это уже совсем другой вопрос.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>А это уже из другой области, из области индиго. У индиго свой хост (ServerEnvironment) и свои особенности. Понятно что это уже сервер приложений в чистом виде.
А вот обо всем этом мы поговорим 15го, ибо я ЕДУ В МОСКВУ!!!!

... << RSDN@Home 1.1.0 stable >>

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

S>А вот обо всем этом мы поговорим 15го, ибо я ЕДУ В МОСКВУ!!!!

Ёу!!

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

ГВ>>В каких-то случаях — да, в каких-то — нет. Не стоит обобщать.

Попробуй для начала сравнить время выполнения поиска в std::map<...> со скоростью проверки констрайнта UNIQUE на сопоставимых объёмах данных.
AS>А если ключ составной? Зачем изобретать велосипед?

Причём здесь характер ключа? Ты посравнивай ради интереса. Да и ключи, они ведь тоже разными бывают.

ГВ>>И не забудь ещё, что в случае нарушения констрайнта у тебя ответ пойдёт через всю прослойку от SQL-сервера до App-сервера.
AS>Ну и что? Я уж лучше доверюсь в шаловливые ручки SQL-сервера, чем в на коленках написанный рукоблудный апп-сервер.

Сколько ругательств... Ну, извини, если уж то, что делают твои коллеги вместе с тобой ты a'priori называешь сделанным "на коленках"... Значит, видимо, аргументы кончились или с командой тебе не повезло.

Ну а если без эмоций, то откуда такое неприятие идей, слегка не вписывающихся в рамки существующих продуктов?

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

>> IT>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.
>>
>> А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.

TK>С каких это пор — получение объекта целиком это не ООП? Объектность как таковая не зависит от того, в каком месте находятся данные.

Забиваем мы на ООП, потому что вместо вполне логичного в этом случае "вытягивания" презентации отдельных атрибутов мы тянем весь букет связанных объектов, распыляя состояния.

Кроме того, есть ещё вагон других приколов. Например, приходится обеспечивать эквивалентность поведения объектов (методов!) совершенно разными средствами: в одном случае это какой-нить JScript, в другом — VBScript, в третьем — C++/C#, в четвёртом — T-SQL. И всё это должно работать адекватно (чёрт с ней с синхронностью, о ней даже вспоминать при таких раскладах страшно). Здорово? ИМХО — нет. Хотя бы потому, что у этих средств совершенно разные возможности и назначения.

>> Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.
TK>Замечательно. Эти документы порождаются в какой-то БД и там остаются.

Идём дальше. Создали объекты в промежуточной БД. Что они отражают? Ответ: они отражают временное промежуточное состояние. Т.е., это и есть реализация stateful. Притом совсем как "клапана через выхлопную трубу", вернее — "RAM средствами SQL-сервера".

Дорассуждались-таки.

>> Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.
>>

TK>Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные, и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.

Проблема совсем не в этом, а в том, что нужно развешивать груду разнообразных флагов в клиентском коде для того, чтобы отследить контекст, в котором выполняются транзакции завершения подчинённых документов. Здесь получается одно из двух: либо ты ты пишешь две разные процедуры выполнения

>> У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.
>>

TK>Бизнес код это логика, работы и к сосотоянию она имеет очень мало отношения.

Мммм... ИМХО, бизнес код, это всё-таки кодирование некоторой абстракции предметной области, а уж коль скоро мы обсуждаем здесь ОО-модели, то и бизнес-код, это всё-таки объекты, следовательно — состояния + методы. Так что, ты не прав...

TK>С тем-же успехом, можно написать достаточно универсальное хранилище, для управления состояними и откатом.

С тем же, это с каким?

TK>И, если посмотреть на развитие индустрии ПО — именно к этому все и движется. Smart приложения набирают все большую популярность — даже возможности сегодняшней ноты могут превосхидить недавние сервера, не говоря уже о десктоп системах. В этой ситуации использование stateless технологий упрощает создание распределенных приложений.

Ага, чтобы мощным ноутам было чем заняться.

>> AVK>>Та же бяка в случае тяжелых и сложных алгоритмов, особенно если они распределенные, правда в этом случае хотя бы от клиента не зависим.
>> IT>С ними всегда бяка.
>> Тем не менее в стейтфул модели бяка поменьше.
TK>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

Почему? Фиксация промежуточных состояний применяется совсем независимо от выбранной "парадигмы" — stateless или stateful. Это как минимум один из способов обеспечения надёжности. Состояния можно сбрасывать, а можно и не сбрасывать. Просто если мы реализуем stateful-модель в памяти App-сервера, то фиксация промежуточных состояний механизмами долговременного хранения информации — порой полезная, но в целом совсем не обязательная фича.

>> IT>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).
>> Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.
TK>Не обязательно. Главное это создание устойчивой инфраструктуры — тогда бизнес программист просто не будет задумываться об этом. Хотя, да. в короткой перспективе stateful это удобно.

Естественно, не обязательно, они ещё могут быть сброшены на пользователя.

Как это нередко в итоге и происходит. Кстати, а почему всё-таки ты всё время поминаешь кратковременную перспективу?

>> IT>Я пока что-то не пойму, откуда такая уверенность что в stateless над БД так и наровят постоянно надругаться.
>> Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.
TK>Тоже самое и в stateful. Необходимость постоянно держать состояние в app сервере увеличивает суммарную на него нагрузку и размазывает ее по времени. Только в случае со stateless проще переложить часть нагрузки на клиента / другой сервер.

Слова одни и те же, но означают совершенно разные вещи. Я тебе всё-таки ещё раз скажу: замерь для интереса время выполнения сопоставимых операций на SQL-сервере и в памяти App-сервера в совокупности со временем доступа к их результатам.

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

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

Ну и что получается? Вместо хранения состояний в памяти заводим для них отдельную БД? Супер! Разница во времени доступа исчисляется порядками: наносекунды против, в лучшем случае — десятков микросекунд.

Мда-а... оптимизация, ничего не скажешь.

[...]

>> IT>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.
>>
>> Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

TK>Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.

И к обеспечению ещё большей нагрузки на каналы. Оптимизация, млин.

А слабосвязанными прекрасно могут быть и stateful-системы. Это вообще вопрос отдельный.

Здравствуйте, Alexey Shirshov, Вы писали:
AS>Не согласен. Или поясни более подробно, что ты имел в виду под процедурной функциональностью.
Ровно то, что диктует серверу, что и когда ему делать. Триггер — это пример процедурной функциональности. Оригинальный SQL полностью декларативен.

S>>В N-tier архитектуре все процедурные аспекты лучше перемещать на сторону апп-сервера, для better maintainability. А вот декларативные аспекты надо всенепременно на уровне storage оставлять. Не столько для того, чтобы проверить целостность всякую, а для semantic query optimization. По любому, генерацию уникального номера документа в соответствии с правилами, принятыми в компании, должен выполнять app-server еще до обращения к базе.

AS>Зачмечательно. Только вот когда ты будешь делать кластер, ты поимеешь серьезные проблемы от синхронизации апп-серверов.
Это только в том случае, если апп-сервер стейтфул

А я этого слова пока не сказал.
AS>Вот поэтому и плохи триггеры (кроме того, что они просто замедляют работу сервера).
Да, именно это я и имею в виду. Триггеры и есть процедурное средство поддержки целостности.
AS>Я за SQL-сервер как средство долговременного хранения бизнес-информации и как средство эффективной работы с ними. Пусть хоть 1000 запросов в секунду придется ему выдерживать.
AS>Городить огород из собственных наработок в таком уском месте — потеря времени и сил. Путь даже в некоторых случаях это может и привести к росту производительности.
Угу.

... << RSDN@Home 1.1.0 stable >>

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

S>А вот обо всем этом мы поговорим 15го, ибо я ЕДУ В МОСКВУ!!!!

Ну если ты, в отличие от предыдущих людей и разов повываешь не только в выходные то есть шанс что поговорим

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>А после этого прежде чем что то поменять нужно начать новую.
Ну да... Вне зависимости от модели.
Если у тебя действие атомарное, то ты по любому транзакцию начал, а потом зафиксировал, и все через БД.

Здравствуйте, AndrewVK, Вы писали:
AVK>Ну если ты, в отличие от предыдущих людей и разов повываешь не только в выходные то есть шанс что поговорим

Ну, я буду 15го на встрече offline community. Командировку уже выбил, послезавтра буду билеты заказывать...

... << RSDN@Home 1.1.0 stable >>

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

TK>>Отложенная запись — это очень опасная операция. Любой сбой, любая потеря данных — все это может серьезно подорвать доверие к такой системе. Данные нужно хранить в месте которе более устойчиво, чем оперативная память (прочь соблазны).

S>Дело не в доверии. Дело в ACID. Отложенные записи — прямая дорога в ад.

Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом. Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.

S>Мы не имеем права отказываться от committed транзакций. Сколько бы уровней ни было, OLTP система обязана убедиться в том, что durability достигнута прежде, чем отрапортовать об окончании транзакции. Точка. В некоторых особо редких случаях это не так важно, но это уже не OLTP система, а что-то другое.

Какая разница, есть для этого термин или нет?

Единственное ограничение — не знаешь, что именно писать в рекламных проспектах.

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

M>Если у тебя действие атомарное, то ты по любому транзакцию начал, а потом зафиксировал, и все через БД.

Вот только когда в пределах одной транзакции у тебя несколько обращений к серверу для модификации это уже как бы не совсем стейтлес

... << RSDN@Home 1.1.2 beta 2 >>

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

M>>Если у тебя действие атомарное, то ты по любому транзакцию начал, а потом зафиксировал, и все через БД.

AVK>Вот только когда в пределах одной транзакции у тебя несколько обращений к серверу для модификации это уже как бы не совсем стейтлес

.

Что, если мы пишем метод который в рамках одной транзакции пишет => читает => обновляет то это уже не stateless метод?

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

ГВ>Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом. Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
Ну это скорее не стериотип, а осознание того факта, что организовывать полноценный ACID собственными силами — развлекуха для экстремалов. Я затрудняюсь себе представить в каких условиях это было бы выгодно, особенно при наличии готового универсального механизма.

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

AVK>Вот только когда в пределах одной транзакции у тебя несколько обращений к серверу для модификации это уже как бы не совсем стейтлес

.
А зачем несколько?
Можно прогнать всю транзакцию и за одно обращение.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом.
Именно об этом я и говорю. Просто отложенная запись и durability — вещи плохо совместимые. MS SQL ухитряtтся совмещать эти два факта благодаря тому, что откладывает запись самих данных. Журнал пишется синхронно. Подтверждение коммита гарантирует сброс на носитель трейлера журнала транзакций.
Фактически речь идет о том, что если ты пообещал Durability, тебе необходимо гарантировать, что отложенные записи не станут потерянными записями даже при application fault.
ГВ>Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
Да нет конечно, вот только ACID уже встроена в СУБД, и это далось им достаточно большой кровью. У меня потеют ладони, когда я думаю о самопальной реализации ACID. Если мы получим полноценное универсальное решение для ACID за пределами RDBMS, нас станут носить на руках и цитировать в учебниках

ГВ>Какая разница, есть для этого термин или нет?

Единственное ограничение — не знаешь, что именно писать в рекламных проспектах.

Ок, главное — два билета на одно место не продать.

... << RSDN@Home 1.1.0 stable >>

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

TK>>С каких это пор — получение объекта целиком это не ООП? Объектность как таковая не зависит от того, в каком месте находятся данные.

ГВ>Забиваем мы на ООП, потому что вместо вполне логичного в этом случае "вытягивания" презентации отдельных атрибутов мы тянем весь букет связанных объектов, распыляя состояния.

ГВ>Кроме того, есть ещё вагон других приколов. Например, приходится обеспечивать эквивалентность поведения объектов (методов!) совершенно разными средствами: в одном случае это какой-нить JScript, в другом — VBScript, в третьем — C++/C#, в четвёртом — T-SQL. И всё это должно работать адекватно (чёрт с ней с синхронностью, о ней даже вспоминать при таких раскладах страшно). Здорово? ИМХО — нет. Хотя бы потому, что у этих средств совершенно разные возможности и назначения.

Бред. Есть единая среда .NET и тот-же C# будет использоваться как на клиенте, как на промежуточных серверах, так и в базе данных. Зачем делать сборную солянку из разных технологий?

ГВ>Идём дальше. Создали объекты в промежуточной БД. Что они отражают? Ответ: они отражают временное промежуточное состояние. Т.е., это и есть реализация stateful. Притом совсем как "клапана через выхлопную трубу", вернее — "RAM средствами SQL-сервера".

Дорассуждались-таки.

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

TK>>Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные, и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.

ГВ>Проблема совсем не в этом, а в том, что нужно развешивать груду разнообразных флагов в клиентском коде для того, чтобы отследить контекст, в котором выполняются транзакции завершения подчинённых документов. Здесь получается одно из двух: либо ты ты пишешь две разные процедуры выполнения

Что за флаги? Проще надо быть...

ГВ>Мммм... ИМХО, бизнес код, это всё-таки кодирование некоторой абстракции предметной области, а уж коль скоро мы обсуждаем здесь ОО-модели, то и бизнес-код, это всё-таки объекты, следовательно — состояния + методы. Так что, ты не прав...

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

TK>>С тем-же успехом, можно написать достаточно универсальное хранилище, для управления состояними и откатом.
ГВ>С тем же, это с каким?

Да что писать... возьмем biztalk — и бизнес логика и управление состоянием текущего бизнес процесса и при необходимости откат. И если посмотрим на реализацию — это не классический app сервер который тупо хостить наборы объектов.

ГВ>Почему? Фиксация промежуточных состояний применяется совсем независимо от выбранной "парадигмы" — stateless или stateful. Это как минимум один из способов обеспечения надёжности. Состояния можно сбрасывать, а можно и не сбрасывать. Просто если мы реализуем stateful-модель в памяти App-сервера, то фиксация промежуточных состояний механизмами долговременного хранения информации — порой полезная, но в целом совсем не обязательная фича.

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

ГВ>Слова одни и те же, но означают совершенно разные вещи. Я тебе всё-таки ещё раз скажу: замерь для интереса время выполнения сопоставимых операций на SQL-сервере и в памяти App-сервера в совокупности со временем доступа к их результатам.

App сервер данные тоже не из воздуха берет, а из того-же SQL сервера. А про оптимальность доставания данных из SQL и из памяти апп сервера уже говорили. Все эти объектные запросы — очень плохо оптимизируются. (например, нужно достать всех клиентов, которые делали за прошлый месяц заказы продукта X) И что? Так-же не забываем — что в случае с app сервером нам нужно держать в памяти не только текущий экземпляр объекта, но и его копию (мы-же не хотим, что-бы один пользователь увидел то, что редактирует другой)

ГВ>Ну и что получается? Вместо хранения состояний в памяти заводим для них отдельную БД? Супер! Разница во времени доступа исчисляется порядками: наносекунды против, в лучшем случае — десятков микросекунд.

Мда-а... оптимизация, ничего не скажешь.

У вас, что inprocess app сервер с отложенной записью (оригинальная конструкция. название у этого сервера есть)? Раз уж наносекунды получаются... Не стоит забывать, что количество обращений для к серверу для statefull и stateless случаев разное.

TK>>Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.

ГВ>И к обеспечению ещё большей нагрузки на каналы. Оптимизация, млин.

А слабосвязанными прекрасно могут быть и stateful-системы. Это вообще вопрос отдельный.

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

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

ГВ>Причём здесь характер ключа? Ты посравнивай ради интереса. Да и ключи, они ведь тоже разными бывают.

Да, их еще несколько может быть. Как насчет кинуть сюда код std::map который будет для быстрого поиска данных не только по целочисленному PK, но и по имени того-же клиента (т.е. ключа два)? На всякий случай еще небольшая опция через некоторое время появится и еще один индекс. Все это храним в app сервере?

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

TK>Да, их еще несколько может быть. Как насчет кинуть сюда код std::map который будет для быстрого поиска данных не только по целочисленному PK, но и по имени того-же клиента (т.е. ключа два)? На всякий случай еще небольшая опция через некоторое время появится и еще один индекс. Все это храним в app сервере?
Тут ты что-то путаешь. Сколько индексов — столько мапов. Они никак друг другу не мешают. Главное — хранить в метаданных список всех мапов, которые надо трогать при изменении свойств объекта (для синхронизации индексов).
Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

... << RSDN@Home 1.1.0 stable >>

Hello, "Геннадий Васильев"

> Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом. Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
>

Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?

Posted via RSDN NNTP Server 1.6

Hello, "Sinclair"
>
> TK>Да, их еще несколько может быть. Как насчет кинуть сюда код std::map который будет для быстрого поиска данных не только по целочисленному PK, но и по имени того-же клиента (т.е. ключа два)? На всякий случай еще небольшая опция через некоторое время появится и еще один индекс. Все это храним в app сервере?
> Тут ты что-то путаешь. Сколько индексов — столько мапов. Они никак друг другу не мешают. Главное — хранить в метаданных список всех мапов, которые надо трогать при изменении свойств объекта (для синхронизации индексов).
> Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

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

Posted via RSDN NNTP Server 1.6

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

Читал-Читал... и решил, что обед в понедельник — идеальное время для философии

>> Ты очень и очень спешишь с обобщениями. Кроме того, хранение состояний в памяти это не "недостаток", как ты утверждаешь, а всего лишь черта stateful-модели. Недостатком оно становится в тех или иных случаях, не более того.

TK>Скажем так — это плохая черта. А в некоторых случаях она может стать очень плохой.

Не всегда... в некоторых случаях выборки в памяти будут на порядки эффективнее, чем выборки из БД. Например — обращение к справочникам... если часто используемые данные не убирать из памяти — постепенно они все подымутся в память. а если еще и сделать в памяти те самые, так любимые многими B+ деревья — то выборка в памяти будет работать не менее эффективно, чем выборка из БД.
Деже если предположить, что нижний уровень поднимет все такие данные в память (MS SQL, например так и сделает) , все равно остается "лишний" промежуточный слой передачи (ODBC/ADO + TCP/IP?), переоформление данных из native вида в объект.
А запросы к справочным данным выполняются не часто, а очень часто.

>> TK>Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает использовать BizTalk или скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий.
>>
>> Угумс. А ещё мы наблюдаем попытку впарить BizTalk.

>>

TK>Ладно BizTalk пока закроем

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

>>
>> TK>Стив Шварц, один из архитекторов СОМ+ и, наверное, еще много чего, когда приезжал в Москву сказал примерно следующее:
>> TK>никаких стейтлесов не существует в природе (ну это прогнал по незнанию — int Add(int x, int y) { return x + y; } это типичный reference пример стейтлесс метода).
>>
>> Но никак не пример stateless-объекта.

Хотя да, такой метод может быть... например, статическим.

>>

TK>Ну это больше похоже на (всем уже здесь любимую) подмену понятий. Естественно, что в случае тех-же веб сервисов никакой речи о полноценных объектах не идет ?

ну не совсем... но реально — WebService — процедурная вещь.. по сути — набор статических методов для загрузки/выгрузки объектов. Чистым ООП такой подход назвать нельзя.
Чистый ООП — это Remoting в режиме Singleton или ClientActivated причем не для Serializable, а для MBR объектов, т.е. все бизнес объекты — MBR, соответственно мы получаем как раз-таки statefull. не SingleCall.

Отчасти ООП — это WebServices с поддержкой сессий. И то лишь отчасти.
На самом деле, для нормальной именно ООП работы подходит только statefull по одной простой причине: в остальных случаях мы получаем, на самом деле, только набор структур с методами работы с ними.

>> На самом деле вопрос несколько шире, чем просто хранение сотояний. Вопрос ещё и в методах обработки этих самых состояний. И кстати, тот ещё вопросик...
>>
TK>Вот именно.

Более того, я сделаю более сильное утверждение, чем сделаное чуть выше:

действительно интерактивную систему принятия решений на основе актуальных данных НЕВОЗМОЖНО сделать в рамках модели стейтлесс.

На предстоящий вопрос почему сразу отвечу в виде леммы:

Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.
Предположение 1. Если режим == стейтлесс и используются Serializable объекты на стороне клиента, значит из (1) и (2) вся работа, связаная с бизнес логикой выполняется через вызовы Serviced объекта (т.е. по сути вызов процедур сервера).
Следствие 1. из (3) получаем, что методы объекту, который отдается клиенту как бы и не нужны (все равно он все должен на сервере делать) единственное, что нужно объекту, который отдается клиенту — методы для некоего упрощения отображения,
типовых операций, которые можно сделать и в виде внешних классов на клиенте.
То есть в случае, если верно (3) — стейтлесс получается не ООП, а процедурным программированием, что откатывает нас назад в развитии программирования, так как почти ничем не отличается от RDBMS
Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.
Предположение 2. Пусть режим стейтлесс и используется не Serializable объекты, а MBR.
Утверждение 3. из (6) мы получаем ровно две стратегии для соблюдения атомарности изменений:
- Стратегия № 1 ( известная как pessimistic locking + Repeatable Read): Мы должны блокировать объект, к которому кто-то получил доступ. Иначе, при начале изменений этим кем-то, все, кто уже получили тот же объект на чтение, будут иметь неактуальные (частичные) данные. В данной стратегии развития, мы получаем, что один человек, взявший в работу объект, не дает работать всем, кому этот объект нужен зачем-либо, пусть даже для join'ов.
- стратегия №2 (на самом деле — их три, близких по смыслу, известных как Versioning, Read Commited, optimistic locking ) либо делать "скрытое копирование" (Versioning, Read Commited) с блокировкой на изменение объекта (Read Commited) или же просто блокировать объект с "отстрелом всех активных "читателей" (optimistic locking) при начале изменений объекта либо при начале транзакции.
Следствие 2. из (7). получаем, что если нам нужна интерактивная система — мы должны использовать изменение через копирование, т.е. Versioning или Read Commited. Причем, optimistic locking нам не совсем подходит, так как "морозит" работу всех остальных клиентов, которые уже работали с объектами, которые кто-то меняет.
Следствие 3. Так как из (6) все объекты — MBR (или, тем более, CBO), значит состояние хранится на сервере, то есть сервер "в курсе" контекста ывполнения тех или иных операций над объектами, так как все изменения требуют копирования объектов, с "привязкой" этих копий к конкретному человеку.
Вывод 2. Из (7) и (9), через (8) мы получаем, что создание интерактивных систем со всегда актуальными данными на базе стейтлесс с использованием MBR невозможно.
Предположение 3. Вернемся к Предположению 1 (1). Итак, Serializable и мы позволяем клиенту делать с объектом(-ами) все, что угодно, а при пересылке его (их) на сервер проверяем валидность действий и либо принимаем транзакцию, либо отменяем.
Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.
Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели.
Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс.

Итак, окончательный вывод: невозможно построение систем интерактивного принятия решений на основе только стейтлес модели.

стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть :

мы взяли из "неизменного" источника товар

ввели количество

возможно исправили цену

Послали запрос и или получили success либо отопнуты по какой-либо причине (например — нет нужного количества товара

>> TK>А дальше начинается самое интересное. Заученное "стайтфул более удобно в разработке" оказывается не всегда верным! Нет, для простых задач и больших серверов оно конечно так, но нельзя-же запросто так городить монстров и раздувать бюджет проекта.
>>
>> Почти справедливое утверждение, но с одной маленькой поправкой — потому что нет серверов, реализующих полновесную и гибкую stateful-модель без существенных ритуальных плясок вокруг её реализации. Точно так же, как нет и достаточной наработанной базы подходов по этому поводу. Точно также, как есть заученное высказывание "зачем изобретать ещё один велосипед", правомерность применения которого нередко представляется очень спорной.

Точно также, как есть совершенно неверное утверждение относително пригодности stateful только для "простых задач и больших серверов".
>>

TK>А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи?
А может их нет потому, что просто никому не пришло в голову их делать, так как "не модно"?

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

TK>Например списывание денег с дебетовых счетов. Компания MTC до сих пор не может отмазаться "воруют" и "куда делись мои деньги" — вот они последствия "обновления с задержкой". Хотя, идея интересная

Главное только не запускать, а то конкуренты глумиться начнут.

Криваая реализация — часть данных обрабатывается AppServer'ом, а часть — напрямую (не утверждаю, что у МТС именно так, но аналогия именно такова.)

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

Так вот, использование stateful даже здесь позволит получить некоторый выигрыш.

TK>Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу...
Да... возможно, но вот актуальность инофрмации в таком случае обеспечивать тем труднее, чем проще переход на оффлайн.
TK>тут может пригодится и локальное хранилище данных и так-же то, что приложение уже само ориентировано на отправку более/менее законченных результатов.
ага, Еще более адекватные данные получаем

>> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то.

TK>Причем, все это время, данные будут сидеть в памяти app сервера. В то время как, stateless сервер уже давно обслуживать новые запросы,
Читай выше, почему такая стратегия не жизненна в любом месте, где нужна строгость в соблюдении точности и актуальности данных.
TK>а эти данные будут лежать в одной из баз данных на среднем уровне (причем несколько frontend серверов могут использовать эту базу одновременно — еще один дополнительный пункт в повышение общей надежности).
Вот пусть и лежат... когда будут сильно мешать — уйдут из кеша. тем более, что дизайн клиента должен быть таким, что транзакций, которые висят "вхолостую" быть не должно.

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

TK>Отложенная запись — это очень опасная операция. Любой сбой, любая потеря данных — все это может серьезно подорвать доверие к такой системе. Данные нужно хранить в месте которе более устойчиво, чем оперативная память (прочь соблазны).
>> Далее возможен сбор статистики и подстройка времени задержки в зависимости от конкретного оператора. Аналогичная история и с формированием справочников. Возможная контраргументация по части надёжности такого подхода отбивается тем, что, например, сбой по питанию машины с SQL-сервером запросто приведёт к непредсказуемым потерям данных, а корректное завершение работы App-сервера естественно подразумевает а) закритие клиентских сеансов и б) завершение буферированных (задержанных) транзакций.
>>

TK>SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает...
Да ну? они даже без потерь питания бывают... вот например есть диск, на котором лог файл.. пусть на этом диске есть всего 100 МБ свободного места если совершить достаточно длинную транзакцию — вся БД падает, причем — невосстановимо. самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то) а при отложеном до конца транзакции сбросе данных в БД места под лог вполне может хватить — все это случай из моего опфта... в транзакции было всего лишь 65000 объектов.
>> Правда, справедливости ради, следует заметить, что реализация такого подхода требует достаточной квалификации и самостоятельности программистов, что, увы, может стать проблемой в современных условиях.
>>
TK>+1
+ еще 1.

>> TK>А вся мощная логика баз данных по распределению данных, созданию grid систем, репликации в конце концов по сути работает в холостую.
>>
>> Ничего подобного. "Вся мощная логика баз данных" высвобождается для других нужд. Например, для сложных отчётов или OLAP/переOLAP, тогда как относительно простую обработку берёт на себя App-сервер, которому даже мощной дисковой подсистемы по большому счёту не нужно.
>>
+1 плюс к тому же, можно в памяти хранить часть особо часто используемых индексов — это даст возможность еще больше разгрузить компьютер, так как на текущий момент самое узкое место всех AppServer'ов да и вообще серверов — это дисковая система.

TK>Ну на счет дисковой подсистемы — это больше заблуждение. Всегда эффективнее держать кеш на локальном диске, чем доставать его по сети... Так-же кеш в оперативной памяти — хранение объектов в памяти это не оптимально. Да, это удобно для программиста — он освобождается от ненужных деталей и т.п. Но, с точки зрения эффективности — это совершенно не оптимально.
TK>Все эти отложенные загрузки, интеллектуальные кеши обеспечение конкуррентности своими руками производительности не прибавляют.
Да? насчет отложеных загрузок — я уже как-то приводил пример с графом объектов.
представь себе, что объекты собраны в граф... нет, пусть будет дерево. в дереве — примерно ну например 64К объектов (совершенно реальная цифра — речь идет о справочнике товаров.
Если мы берем вариант совсем без отложеной загрузки, то:

Либо мы утягиваем с сервера, при любом неосторожно запросе, весь граф объектов (а нам-то нужен был только один).
Либо мы должны реализовывать отложеную загрузку своими руками, что сводит на нет одну из сильных сторон и аргументов в пользу AppServer'ов, ибо мы просто запрещаем таким образом хранить ссылочные данные.

TK>С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям.
Далеко не все. Проверено.
Например — как в нем нормально хранить счетные данные типа вот такого:

у нас есть дерево и на каждом кровне нам нужно иметь в узле статистику по поддереву, которая считается рекрсивно.
Я думаю, что через известное отверстие даже такой случай можно будет разрулить с помощью indexed view, но какой ценой??? И сколько будет стоить изменение какой-либо части алгоритма?
В AppServer'е, использующем собственные (хранимые) индексы можно хранить даже такую экзотическую вещь.

>> Нет, не только кэш. Ещё и взаимодействие с чем угодно, с чем не может непосредственно взаимодействовать СУБД. Да и о критериях эффективности управления данными знает исключительно App-сервер, поскольку только ему они и сообщаются непосредственно. По идее, разумеется.

Конкретный App-сервер может ни шиша не знать о прикладной специфике.

>>

TK>"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения...
Ну не совсем.. часть данных, которые есть в AppServer'е могут быть, например, показаниями датчиков.. снимаемые в реальном времени. и ты об этом даже не узнаешь, так как они НИЧЕМ не отличаются от "обычных" бизнес объектов.

>> TK>Вот и получается интересная ситуация — большая часть чем занимается наш AppСервер — это управляет кешем, навязывает базам данных свои транзакции
>>
>> Угу, а заодно он ещё может их оптимизировать, поскольку от сложной многосвязной транзакции останется только пачка insert/update, не задействующих триггеры и прочие далеко не самые эффективные механизмы контроля целостности БД.
>>
+1

TK>Триггеры это не только контроль целостности данных, но и еще один дополнительный уровень абстракции данных. А если учесть, что пишут их специальные люди которые о БД знают больше, чем абстрактный App сервер. то эффективность от использования триггера и того, что там насоздает абстрактный app сервер еще надо детально оценивать для каждого конкретного случая.
А так — можно будет во многих случаях обойтись без этих специальных людий и посадить только одного такого Гуру (с большой буквы) который напишеть модуль O-R mapping'а и все.

>> TK>(все в курсе на как падает производительность при использовании распределенных транзакций в COM+) и хранит в общем-то редко используемые данные...
>>
>> А вот это, кстати, косвенно подтверждает тезис о снижении производительности OLTP в stateless-модели.

Второе аналогичное подтверждение состоит в том, что в тестах TPC-C MS использовала COM+ только для чтения данных, а обновление запускались через обычный ODBC. Что, в принципе, логично, если рассматривать stateless-модель в её естественной ипостаси — как удобной модели для трансформации представления данных.
>>

TK>Что значит чтение данных через COM+? Из SQL Server можно читать данные используя ODBC или OLE DB. COM+ это уже внешний сервис который к БД не так уж и много отношения имеет. Может они просто для записи в COM+ транзакции отключали?

>>
>> TK>И в итоге — стайтфул модель оказывается плохо масштабируемой. добавить просто так еще один сервер нельзя — нужно обеспечить согласованность внутренних кешей и т.п. остается — только наращивать производительность одной конкретной машины или вводить элементы stateless модели.
>>
Да ну? Я вон тока сегодня рассказывал Синклеру вариант написания Service-oriented систем при использовании стейтфул модели.
>> Ухх... в итоге получается нечто, достойное рекламной статьи на сайте Microsoft, уж извини. Ты утверждаешь, что нельзя обеспечить согласование кэшей? А на основании чего ты так говоришь? Уж не основании ли того, что у тебя в распоряжении нету компонента "StatefulCacheSyncronizer"?

>>
TK>Я не спорю, можно обеспечить соглосование кешей, и прочих замечательных вещей. Возможно, что компоненту "StatefulCacheSyncronizer" можно купить в каком нибудь электронном магазине. Разговор о том, что насколько эффективно писать подобные компоненты в своем подразделении, или насколько велик бюджет проекта для покупких сервера (не только ПО, но и железо. Не будем забывать, что при увеличении производительности стоимость сервера растет не пропорционально) приложений с нужной функциональностью.
правильно.. при увеличении производительности сервера цена сперва растет логарифмически, потом — экспоненциально (второе — совсем недолго) но в результате рост получается ниже линейного. Говорю как краеевед — я иногда железяками торгую, так что стараюсь быть в курсе.
>> TK>В противоположность ей стайтлесс модель на таких данных ведет себя хорошо, поскольку гибкие возможности современных быз ранных, обладающих большей информацией о механизмах хранения данных (все основано на серьезном математическом аппарате), эффективных средствах кеширования и распределения информации — не вносит практически никакого оверхеда, но предоставляет поистинне фантастические возможности для масштабирования. Редко меняющиеся данные спокойно могут реплицировать на десяток не особо мощных машин, и когда будут идти обращения к БД, они не будут испытывать практически никаких блокировок — поскольку вся архитектура является распределенной и выполнять эту работу будет наименее загруженный участник.
>>
Да только вот незадача — как уже писалось выше

ну не подходит стейтлес для интерактивных приложений...

TK>Распределенным может быть хранение данных.
TK>1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер.
Насчет количества блокировок на отдельном сервере — согласен, а вот длительность блокировок будет длиннее, так как при завершении транзакции более сложной, чем изменение одной записи в одной некластеризованой таблице потребует (с большой вероятностью) согласования между серверами, распределенных транзакций, что лишь повысит нагрузку на сервер при блокировке... так что тяжело решить однозначно что тут лучше — от задачи зависит.
Кстати, бывают задачи, вообще не вызывающие блокировок... никогда.
TK>2. Редко изменяемые данные реплицируются на локальные базы ближе к frontend серверам. Учитывая, что репликация происходит только измененной информации — нагрузки будут минимальными. И практически мгновенное отображение изменений.
Ну, в общем и целом — таки да. тут хорошо, что не отменяет той же возможности в стейтфул.
>> TK>Было одно преимущество стейтфул модели — считается, что прог
>>раммирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, правда обращение к объекту требует потокобезопасности (кого это сейчас пугает?). Но, современные средства такие, как BizTalk сервер не только предоставляют удобные стредства для программирования бизнес логики, но и имеют массу шлюзов в уже имеющиеся системы.
>>
>> Угу, продажа BizTalk уже началась.

>>

TK>Ну, BizTalk рулит. Кстати, тоже, как и stateless сервисы легко масштабируется — дополнительный плюс от того, что состояние каждого бизнес процесса хранится не в памяти, а в базе данных.
нет... главное тут, что состояние хранится, а где — неважно... можно и в памяти с рассылкой/запросом/оповещением

ЗЫ ко всему сразу... начал я писать этот ответ примерно в 09:00 по Москве, так что ежели чего пропустил — не обессудьте

... << RSDN@Home 1.1.2 beta 1 >>

Hello, "Hacker_Delphi"

> TK>Скажем так — это плохая черта. А в некоторых случаях она может стать очень плохой.
>
> Не всегда... в некоторых случаях выборки в памяти будут на порядки эффективнее, чем выборки из БД. Например — обращение к справочникам... если часто используемые данные не убирать из памяти — постепенно они все подымутся в память. а если еще и сделать в памяти те самые, так любимые многими B+ деревья — то выборка в памяти будет работать не менее эффективно, чем выборка из БД.

Ну, сразу на вскидку — да, справочники меняются редко, но они меняются. Это можно списывать на плохой дизайн, на ошибки разработчиков и т.п. но никуда от этого не уйти — придется продумывать политику кеширования этих справочников, обновления кеша и т.д.
Что касается B+ деревьев — лично я их глубоко уважаю и никаких притезий к ним не имею. Но, возьмем любой самый завалящийся справочник — что хотят видеть пользователи: он начинает выбирать запись, вводит первую букву и тут бац — выпадает список где все слова на букву "A", после этого он нажимает "B" и все слова на букву "AB", ну а потом он еще и стрелками до нужной записи дощелкает. А в другом случае этот гадский пользователь откроет документ и тут нам понадобится поиск нужной записи по ID. Тут, конечно, B+ деревья всеми ветвями за. Но насколько это нам нужно? Сделать свою in memory database и показать кукиш этим гадам, что требуют лицензионных отчислений за использование своих БД?
Ну и не забываем, что мы сильно ограничены объемом оперативной памяти. А как-же всеми любимый своп файл? Он и рядом, да базу данных тоже, всю в память не затащишь... а вот тут-то и заключается вся загвоздка — кончается у нас память, приходит товарищ GC и начинает прибираться, достает одну страничку из свопа, другую (а сервер в это время стоит — ждет пока этот "мойдодыр" все до синевы не вычистит). Он конечно быстрый, но своп файл ему быстро ноги пообломает... А какая со сломанной ногой уборка? правильно — никакой. Мучение это одно.. А вот у базы данных проблем с уборкой нет. Нужна память? пожалуйста — просто сбросили страничку с данными на диск и никаких тебе проблем. а уж что до синхронизации — тут у базы данных все просто в шоколаде. просто реплицируем справочники на локальные машины... какие изменения в справочнике? нет проблем! Это берет на себя база данных.

> Деже если предположить, что нижний уровень поднимет все такие данные в память (MS SQL, например так и сделает) , все равно остается "лишний" промежуточный слой передачи (ODBC/ADO + TCP/IP?), переоформление данных из native вида в объект.

В случае с MS SQL на локальной машине использовать TCP/IP совсем не обязательно — он может использовать shared memory протокол. Скажу сразу — shared memory в сравнении с TCP/IP это не просто быстро, а очень быстро...

> А запросы к справочным данным выполняются не часто, а очень часто.
>

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

>
> TK>Ну это больше похоже на (всем уже здесь любимую) подмену понятий. Естественно, что в случае тех-же веб сервисов никакой речи о полноценных объектах не идет ?
>
> ну не совсем... но реально — WebService — процедурная вещь.. по сути — набор статических методов для загрузки/выгрузки объектов. Чистым ООП такой подход назвать нельзя.

Никто особенно не возражает, но не забываем, что у веб сервиса все таки есть какой никакой контекст. Текущий пользователь, SOAP заголовки туда обратно... Да и мало-ли чего. Подведя итог можно сказать смело от процедурного "Hello world" эти ребята далеко ушли.

> Чистый ООП — это Remoting в режиме Singleton или ClientActivated причем не для Serializable, а для MBR объектов, т.е. все бизнес объекты — MBR, соответственно мы получаем как раз-таки statefull. не SingleCall.
>

Так кто возражает. MBR и stateful — близнецы братья и вообще не разлей вода (если мы используем настоящий ремотиг. а не какую-нибудь подставу).

> Отчасти ООП — это WebServices с поддержкой сессий. И то лишь отчасти.

Кстати — в WebServices еще куча всего дуругого есть (кроме дурацких сессий). Но это только кстати.

> На самом деле, для нормальной именно ООП работы подходит только statefull по одной простой причине: в остальных случаях мы получаем, на самом деле, только набор структур с методами работы с ними.
>

Несколько странное утверждение — получается, что объекты нужно править по месту. а если мы его куда забрали, то это и не ООП вовсе.
А так, структура, с методами

Ну а обсуждение НЕВОЗМОЖНОЙ леммы продолжим в следующей серии

Posted via RSDN NNTP Server 1.6

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

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

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

S>Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

И когда будешь обновлять мапы не забудь залочить свой app-сервер во избежании undefined behaviour.

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

S>В свете этого введение unique constraint на уровне RDBMS кажется избыточным.

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

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

Tom>>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации.
Tom>>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД.
Tom>>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.

IT>При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах.
ну оно конечно так, али ж трошэчку не так. синглетон ты с 1 не реализуеш. да и вообще метод 1 наверно более подходит к стэйтлесс. из всего обсуждения прояснилась действительно не плохая мысль о хранении редко изменяемых данных где то по ближе, чем бд. а таких вроде как хватает. что скажешь?

IT>В общем, не на том акцентируете внимание, товарищи.
Угу. Тут попробуй сказать что нить. Так сразу или 'стэйтфульщик' или ещё чего

... << RSDN@Home 1.1 beta 1 >>

Здравствуйте, IT, Вы писали:
IT>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.
Хм. По-моему это все же максимализм. Щас не могу с точностью сформулировать пример, но я бы поостерегся выполнять все возможные проверки средствами БД.
IT>При этом валидацию данных сервером приложений никто не отменяет. Более того, некоторые правила бизнес-логики можно проверить только средствами сервера приложений. Но тем не менее игнорирование контроля целостности данных сомой БД может привести к неправильной работе самого сервера приложений при 'непреднамеренной' порче данных, что скорее всего при данном подходе приведёт к краху всей системы.

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

Ок, прошу прощения за несколько фривольный тон — в азарте погорячился. Вместо "фигня" читать "я не вполне согласен с вышесказанным".

... << RSDN@Home 1.1.0 stable >>

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

AVK>А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.

Вот что и требовалось доказать

AVK>Вытянув мы кажем его пользователю и позволяем редактировать. В это время все что требуется от сервера это обеспечивать подкачку если данные слишком большие чтобы тянуть их одним куском. А вот когда этот документ записывается обратно и начинаются интересные вещи. Первичка порождает целую толпу завязанных на него объектов. Эти объекты не нужны на клиенте, их не надо туда пихать.
AVK>Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.

Не вижу проблемы

Хотя пожалуй вижу одну

AVK>Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?

Дать ему уникальный guid при создании.

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

AVK>У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.

Откуда сделан такой вывод? Пока я вижу, что ты не теми средствами решаешь поставленную перед тобой задачу. Возьми BizTalk и не мучайся (правда он стоит зараза), переписывать бизнес-правила тебе не придётся. Только перерисовывать

IT>>Т.е. ты всё же клонируешь объект?

AVK>В бизнес-коде нет, на клиента во многих случаях да.

Значит сервер у тебя занимается также синхронизацией и версионностью.

IT>>Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

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

Ты делаешь свою систему как коробочный продукт или на заказ/для своей конторы? Если первое, то пожалуйста. Если второе, то ничем от отдела автоматизации такая работа не отличается. Твоя задача не изобрести ещё один BizTalk, а максимально быстро и с наименьшими затратами решить поставленную задачу.

IT>>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

AVK>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

Это тут при чём? Или у стэйтфул программистов есть секретарши, которым они надиктовывают свой код? Код то всё равно писать

IT>>Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.

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

Ничего оно не ограничивает. А совсем наоборот. Благодаря простоте реализации stateless оставляет больше времени, чтобы бегать по этим просторам.

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

AVK>Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.

Ну и как это противоречит stateless модели?

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

AVK>Хороши усилия — после каждого запроса скидывать состояние в БД

Подожди, подожди. А разве у тебя состояние объектов может не соответствовать их состоянию в БД?

IT>>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию

, давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.

AVK>Зря.

Зря что не отличаются?

IT>> Что там управление предприятиями, что тут,

AVK>Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.

Порядки начисления — это бизнес логика.

IT>>Слова мужа

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

AVK>Слова Стива Шварца помнишь?

Какие именно

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

AVK>Отстал от жизни

Всё течёт, всё развивается. Где-то я отстал, где-то ты изобретаешь велосипед. Жизнь

AVK>>>Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.

IT>>Возможно. Насочинять можно много чего.

AVK>Ну он вроде как говорил где именно та или иная схемка реализована на практике.

На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.

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

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

AVK>Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе.

Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок

AVK> Кроме того не следует пытаться надуть муху до размеров слона. Если начинали с решения для малых предприятий пытаться потом получить из этого кластерного монстра неразумно.

Ты так думаешь потому что тебе это просто пока не приходилось делать

AVK>>>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.

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

AVK>Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

Что-то я тут опять мало что понял. Закладвать в архитектуру расширяемость можно и нужно всегда. Неумение это делать — это уже недостатки не архитектуры, а архитектора

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

IT>>При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах.
Tom>ну оно конечно так, али ж трошэчку не так. синглетон ты с 1 не реализуеш. да и вообще метод 1 наверно более подходит к стэйтлесс. из всего обсуждения прояснилась действительно не плохая мысль о хранении редко изменяемых данных где то по ближе, чем бд. а таких вроде как хватает. что скажешь?

Думаю, что дело синглетон здесь не при чём

IT>>В общем, не на том акцентируете внимание, товарищи.
Tom>Угу. Тут попробуй сказать что нить. Так сразу или 'стэйтфульщик' или ещё чего

Не. По наклеиванию ярлыков у нас есть другие специалисты.

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

IT>>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.
S>Хм. По-моему это все же максимализм. Щас не могу с точностью сформулировать пример, но я бы поостерегся выполнять все возможные проверки средствами БД.

Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.

IT>В общем, не на том акцентируете внимание, товарищи.
Сделал мааааленький тестик. Если хранить таблицу users просто в датасете, то получается ~ 1mb per 1.000 users. Т.е всего 20mb пер олл юзерс. Можно ещё последних ~10 тысяч сообщений хранить. Вроде как памяти хватает а сиквел это должно порядочно разгрузить.

поправь меня если я тут это

не прав в общем

... << RSDN@Home 1.1 beta 1 >>

IT>Думаю, что дело синглетон здесь не при чём

Я наверно не правильно выразился. Модель 1 вообще не подходит для state full.

... << RSDN@Home 1.1 beta 1 >>

TK>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?
А что это трудно сделать? Вроде как нет

А на нэте вообще можно красоту с контекстами придумать

... << RSDN@Home 1.1 beta 1 >>

TK>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.

ну ну. вот тебе тестик:

using System;
using System.Data;
using System.Data.OleDb;
using System.Data.Common;
using Microsoft.ApplicationBlocks.Data;

namespace _70
{
    class Class1
    {
        public static String connStr = @"Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=RSDN;Data Source=PC31";

        static void M1()
        {
            try
            {
                String reqSql = "SELECT * FROM users WHERE userid=4";
                for (int i=0; i<1000; i++)
                    SqlHelper.ExecuteDataset(connStr, System.Data.CommandType.Text, reqSql, null);
            }
            catch(Exception e)
            {
                Console.WriteLine(e.Message);
            }
        }

        static void M2()
        {
            try
            {
                String reqSql = "SELECT * FROM users";
                DataSet ds = SqlHelper.ExecuteDataset(connStr, System.Data.CommandType.Text, reqSql, null);

                for (int i=0; i<1000; i++)
                    ds.Tables[0].Select("userid=4");
            }
            catch(Exception e)
            {
                Console.WriteLine(e.Message);
            }

        }

        [STAThread]
        static void Main(string[] args)
        {
            M1();
            M2();

            Console.WriteLine("Mem cleaned!");
            Console.ReadLine();
        }
    }
}

попробуй выполнить и прочувствовать разницу.
у меня профайлер сказал:
M1 — 4,290
M2 — 165

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

... << RSDN@Home 1.1 beta 1 >>

здесь много вкусного

... << RSDN@Home 1.1 beta 1 >>

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

TK>>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?
Tom>А что это трудно сделать? Вроде как нет

В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.

... [RSDN@Home 1.1.0 stable]

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

Tom>поправь меня если я тут это

не прав в общем

Да легко.. А сделай, по бырому, тестик с группировкой, top 100 например..

... [RSDN@Home 1.1.0 stable]

M>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
Что значит опаньки. Имелось в виду что то типа транзакций для состояния обьектов в оперативной памяти. e/g в методе произошёл эксепшин — все изменения состояния обьекта, произведённые в данном методе откатываются на момент до вызова. А если отключилось электричество то нужно бежать в магаз за

покуда есть такая чудная возможность

ЗЫ: Считается, что современные винчестеры должны обеспечивать гарантированное завершение начатой save операции. Для этого по питанию ставят кондёры, энергия которых, используется при проподании питания.

... << RSDN@Home 1.1 beta 1 >>

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

Tom>Сделал мааааленький тестик. Если хранить таблицу users просто в датасете, то получается ~ 1mb per 1.000 users. Т.е всего 20mb пер олл юзерс. Можно ещё последних ~10 тысяч сообщений хранить. Вроде как памяти хватает а сиквел это должно порядочно разгрузить.

Сообщения у нас и так кешируются. Только не десять тысяч последних, а те к которым было недавнее обращение.

Tom>поправь меня если я тут это

не прав в общем

Неправ. Сообщения у нас кешируются не потому что sql сервер не успевает, а потому что расцветка синтаксиса тормозит. Вот и делай теперь выводы

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

Tom>ЗЫ: Считается, что современные винчестеры должны обеспечивать гарантированное завершение начатой save операции. Для этого по питанию ставят кондёры, энергия которых, используется при проподании питания.

Ага, на пару фарад

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

M>>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.
Tom>Что значит опаньки. Имелось в виду что то типа транзакций для состояния обьектов в оперативной памяти.
Что значит "типа"? одно из свойств ACID, а именно D, подразумевает, что если транзакция зафиксировалась, то откатить ее уже нельзя никаким образом. Вообще. Как ты ее собираешься в памяти фиксировать?

Tom> e/g в методе произошёл эксепшин — все изменения состояния обьекта, произведённые в данном методе откатываются на момент до вызова.
Ок, эксепшена не произошло, сказали commit, чего делаем? Данная транзакция уже стала историей, причем необратимой. На основе произведенных ею действий и внесенных изменений, начали работать другие транзакции.
А она у тебя по прежнему в оперативке, как я понял. Теперь какая-нибудь фигня случилась и не дошла твоя транзакция до диска, бывает. Получается, что другие транзакции работали с данными, которые на самом деле не существовали. Транзакции-то твоей нет больше.. Вот и опаньки. Вариантов не много, надо все другие транзакции, которые работали на основе той, что в памяти осталась и до диска не дошла, тоже откатывать надо. Но они тоже могли успеть зафиксироваться и на их данных могли начать работать другие транзакции...
Cascading Abort это называется, и все БД подобного сценария всячески избегают.
Концепцию БД, в принципе, тоже не глупые люди придумывали...

Tom>ЗЫ: Считается, что современные винчестеры должны обеспечивать гарантированное завершение начатой save операции.
А когда ты ее начать успел? У тебя же все в памяти....

... [RSDN@Home 1.1.0 stable]

Hello, "Tom"
> TK>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.
>
> ну ну. вот тебе тестик:
>

[skip такому тестику]

>
> попробуй выполнить и прочувствовать разницу.
> у меня профайлер сказал:
> M1 — 4,290
> M2 — 165
>
> Просто в последнее время стало модным забивать и забиватся на сервер БД. Ну не эффективно это во многих случаях и приходится ручками лепить довольно много. Не надо делать из сервера БД — спасателей, которые всегда спешат на помощь (c) TK.

А теперь давай положим в эту табличку пару миллионов записей, и начнем выбирать данные из случайного места. И еще не забудь добавить в свой тестик обновление кеша — данные меняются и кеш надо иногда перезагружать. А для пущей реальности, добавим еще пару табличек роли — там какие-нибудь и еще какой-нибудь ерунды в том-же стиле... Плюс сделаем вид, пользователи иногда логинятся — так что, поищем еще и по имени...
И тогда, мы еще раз поиграем в спасателей. Только боюсь как-бы M2 не пролетел мимо дерева

Posted via RSDN NNTP Server 1.8 beta

Hello, "Tom"
> TK>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?
> А что это трудно сделать? Вроде как нет

Не сказать, что просто.

> А на нэте вообще можно красоту с контекстами придумать

Вот только пока кроме ведения логов — в голову никому больше ничего не лезет ;-\

Posted via RSDN NNTP Server 1.8 beta

Hello, "Hacker_Delphi"

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

действительно интерактивную систему принятия решений на основе актуальных данных НЕВОЗМОЖНО сделать в рамках модели стейтлесс.

> На предстоящий вопрос почему сразу отвечу в виде леммы:
>

Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.

+1 stateless. Логика так-же остается на сервре. Клиент только готовит первичные данные.

>

Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.

+1 stateless. только первичные данные.

>

Предположение 1. Если режим == стейтлесс и используются Serializable объекты на стороне клиента, значит из (1) и (2) вся работа, связаная с бизнес логикой выполняется через вызовы Serviced объекта (т.е. по сути вызов процедур сервера).

Не совсем так... Не зря пртокол назвается SOAP и Web метод тоже не спроста.

>

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

Ну, самый простой бизнес процес из нашей, так сказать, жизни.
Вот собрался Синклер приехать к нам 15-го на встречу, ну и пообщаться тоже. На работе ему это оформляют под это дело командировку, дают командировочные, когда приедет — устроится в гостинницу (может и нет — смотря по реализации), потом мы сходим в Ms, посидим там, дальше поедем пить пиво, купим пиццы и т.п. (кстати — предположим ему компания оплачивает только две пиццы, а купили 3), дальше пиво допили, разъехались, Синклер вернулся домой, отчитался за командировочные (а может и нет — ну, потерял бумажки) и на этом процесс завершился. Все предельно просто.

Вот опиши в двух словах как используюя ООП (так чтоб с наследованием, полиморфизмом и никаких процедур) и statefull сервера реализовать платформу для выполнения данного бизнес-процесса (командировка, пиво, пицца, возврат назад, отдача командировочных и взаимо-расчет)?

>

Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.

Не надо так утрировать. Документы отправляемые на сервер могут содержать достаточно много информации, что-бы считать веб метод обычной процедурой.

>

Предположение 2. Пусть режим стейтлесс и используется не Serializable объекты, а MBR.

А зачем использовать стейтлесс и MBR? Или это доказательство по индукции (типа так полохо, так тоже плохо — значит по любому плохо)?

>

Утверждение 3. из (6) мы получаем ровно две стратегии для соблюдения атомарности изменений:
>

стратегия №2 (на самом деле — их три, близких по смыслу, известных как Versioning, Read Commited, optimistic locking ) либо делать "скрытое копирование" (Versioning, Read Commited) с блокировкой на изменение объекта (Read Commited) или же просто блокировать объект с "отстрелом всех активных "читателей" (optimistic locking) при начале изменений объекта либо при начале транзакции.

А зачем делать копирование, если и так используется stateless? Точно от противного...

>

Предположение 3. Вернемся к Предположению 1 (1). Итак, Serializable и мы позволяем клиенту делать с объектом(-ами) все, что угодно, а при пересылке его (их) на сервер проверяем валидность действий и либо принимаем транзакцию, либо отменяем.
>

Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.

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

>

Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели.
>

Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс.
>

Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать.

> стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть :
>

>
>
мы взяли из "неизменного" источника товар
>
ввели количество
>
возможно исправили цену
>
Послали запрос и или получили success либо отопнуты по какой-либо причине (например — нет нужного количества товара
>

>

Это совсем простая схема. В реальности — все на много сложнее.

> TK>А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи?
> А может их нет потому, что просто никому не пришло в голову их делать, так как "не модно"?

>

так-же как и транзакции в памяти (зато быстро).

> TK>Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу...
> Да... возможно, но вот актуальность инофрмации в таком случае обеспечивать тем труднее, чем проще переход на оффлайн.

Какие трудности видишь?

> >> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то.
>
> TK>Причем, все это время, данные будут сидеть в памяти app сервера. В то время как, stateless сервер уже давно обслуживать новые запросы,
> Читай выше, почему такая стратегия не жизненна в любом месте, где нужна строгость в соблюдении точности и актуальности данных.

строгость в соблюдении точности и актуальности данных плохо согласуются с ручным / полу ручным вводом накладных. Так-же ничто не мешает и stateless делать все необходимые проверки.

> TK>SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает...
> Да ну? они даже без потерь питания бывают... вот например есть диск, на котором лог файл.. пусть на этом диске есть всего 100 МБ свободного места если совершить достаточно длинную транзакцию — вся БД падает, причем — невосстановимо. самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то) а при отложеном до конца транзакции сбросе данных в БД места под лог вполне может хватить — все это случай из моего опфта... в транзакции было всего лишь 65000 объектов.

В stateless у тебя вряд-ли будет задейтвованно такое количество объектов... все ориентированно именно на короткую работу.

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

Ну, имитацию БД в рамках App сервера мы уже обсуждали...

> Да? насчет отложеных загрузок — я уже как-то приводил пример с графом объектов.
> представь себе, что объекты собраны в граф... нет, пусть будет дерево. в дереве — примерно ну например 64К объектов (совершенно реальная цифра — речь идет о справочнике товаров.
> Если мы берем вариант совсем без отложеной загрузки, то:
>

Либо мы утягиваем с сервера, при любом неосторожно запросе, весь граф объектов (а нам-то нужен был только один).
>

Либо мы должны реализовывать отложеную загрузку своими руками, что сводит на нет одну из сильных сторон и аргументов в пользу AppServer'ов, ибо мы просто запрещаем таким образом хранить ссылочные данные.
>

Вобщем — что-бы использовать stateless стоит пересмотреть архитектуру.

> TK>С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям.
> Далеко не все. Проверено.
> Например — как в нем нормально хранить счетные данные типа вот такого:
>

у нас есть дерево и на каждом кровне нам нужно иметь в узле статистику по поддереву, которая считается рекрсивно.
> Я думаю, что через известное отверстие даже такой случай можно будет разрулить с помощью indexed view, но какой ценой??? И сколько будет стоить изменение какой-либо части алгоритма?
> В AppServer'е, использующем собственные (хранимые) индексы можно хранить даже такую экзотическую вещь.

При желании — я в БД так-же могу построить индекс и по дереву. В чем приемущество AppServer который будет его каждый раз грузить на себя все данные и перестраивать индекс не ясно...

> TK>"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения...
> Ну не совсем.. часть данных, которые есть в AppServer'е могут быть, например, показаниями датчиков.. снимаемые в реальном времени. и ты об этом даже не узнаешь, так как они НИЧЕМ не отличаются от "обычных" бизнес объектов.
>

Каждый датчик так-же может не отличаться от обчной stateless службы.

> А так — можно будет во многих случаях обойтись без этих специальных людий и посадить только одного такого Гуру (с большой буквы) который напишеть модуль O-R mapping'а и все.
>

Вот читал форум по java — там до сих пор нормальные реализации O/R мапперов ищут. Так-же не забывай, что материализация объектов это тоже не самая быстрая операция.

> правильно.. при увеличении производительности сервера цена сперва растет логарифмически, потом — экспоненциально (второе — совсем недолго) но в результате рост получается ниже линейного. Говорю как краеевед — я иногда железяками торгую, так что стараюсь быть в курсе.

Что-же тогда google мега кластер не забабахали?

> >>
> Да только вот незадача — как уже писалось выше

ну не подходит стейтлес для интерактивных приложений...

>

Это на твой взгляд

> TK>1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер.
> Насчет количества блокировок на отдельном сервере — согласен, а вот длительность блокировок будет длиннее, так как при завершении транзакции более сложной, чем изменение одной записи в одной некластеризованой таблице потребует (с большой вероятностью) согласования между серверами, распределенных транзакций, что лишь повысит нагрузку на сервер при блокировке... так что тяжело решить однозначно что тут лучше — от задачи зависит.

что тебе так дался этот кластер? одну таблицу так-же можно на несколько серверов растащить... и без кластера.

> ЗЫ ко всему сразу... начал я писать этот ответ примерно в 09:00 по Москве, так что ежели чего пропустил — не обессудьте

Мы тут так долго сотояние не держим =)

Posted via RSDN NNTP Server 1.8 beta

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

ГВ>>Гхм. Отвечу по своему... ммм... опыту.

Может! Только общая скорость обработки упадёт.
IT>Может упадёт, а может и нет, всё зависит от задачи. Так в стэйтфул ты пытаешься решать проблему даже ещё не зная, существует ли она на самом деле. Оптимизацию запросов и кеширование в стэйтлес никто не отменял. Но делать это можно не только на этапе разработки, но и во время эксплуатации, наблюдая за поведением системы. А это означает прежде всего сокращение сроков разработки.

Да, всё правильно. Только никто не запрещает проводить аналогичные мероприятия и в ходе эксплуатации stateful-системы.

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

ГВ>>В точку. С той лишь разницей, что эта БД — специализированная и потому более эффективно работающая.
IT>Кто тебе сказал, что более эффективно

Потому что для того и проектируется.

IT>Оптимизаторы запросов реляционных БД шлифуются уже десятилетиями. Писать же выборку по двум-трём связанным бизнес сущностям в памяти ты будешь сам во время отведённое тебе на разработку. Оптимизировать этот запрос ты тоже будешь сам.

Во время, отведённое мне на разработку чего?

А оптимизация... Не так страшен чёрт, как...

IT>>>Ну и что? В стэйтфул вся оптимизация выборки данных работает в холостую и на сложных запросах неизвестно ещё что хуже.
ГВ>>Ты о чём?

Откуда обобщения?
IT>Оттуда, откуда и у АВК. От балды.

Ну тогда аргумент отклоняется.

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

ГВ>>Т.е., по сути — превращение stateless в stateful?

IT>Кешь и стэйтфул — это далеко не одно и тоже. Мне не нужно синхронизировать каждый объект и мне не нужно сложных механизмов для этого. Кеширование справочников и сброс кеша при изменении в БД пишется на коленке. А если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту, ...

С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?

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

Истинно так.

ГВ>>Или в терминах Шварца — перемещение в сторону бОльшей длительности хранения промежуточных состояний. Только не забудь о том, что от проблемы синхронзации кэшей в том или ином виде ты не освобождаешься.

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

Ну спасибо, просвятил.

[skip обсуждение структуры RSDN]

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

Раз на раз не приходится.

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

Угу.

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

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

ГВ>>Причём здесь характер ключа? Ты посравнивай ради интереса. Да и ключи, они ведь тоже разными бывают.

TK>Да, их еще несколько может быть. Как насчет кинуть сюда код std::map который будет для быстрого поиска данных не только по целочисленному PK, но и по имени того-же клиента (т.е. ключа два)?

Значит — и мапов тоже два.

TK>На всякий случай еще небольшая опция через некоторое время появится и еще один индекс. Все это храним в app сервере?

Нет, не всё и не всегда. Только тогда, когда это оправдано.

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

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

IT>Не забудь так же обновить все мапы, которых коснётся уменьшение зарплаты Петрову за прогулы.

Если нужно будет — то почему и не обновить? Кстати, ещё один вопрос: как соотносится время выполнения std::map::insert() со временем INSERT INTO?

S>>Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

IT>И когда будешь обновлять мапы не забудь залочить свой app-сервер во избежании undefined behaviour.

Э-э-э... знаешь ли... мапы тоже могут быть версионными.

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

TK>Hello, "Hacker_Delphi"

TK>Ну и не забываем, что мы сильно ограничены объемом оперативной памяти. А как-же всеми любимый своп файл? Он и рядом, да базу данных тоже, всю в память не затащишь... а вот тут-то и заключается вся загвоздка — кончается у нас память, приходит товарищ GC и начинает прибираться, достает одну страничку из свопа, другую (а сервер в это время стоит — ждет пока этот "мойдодыр" все до синевы не вычистит). Он конечно быстрый, но своп файл ему быстро ноги пообломает... А какая со сломанной ногой уборка? правильно — никакой. Мучение это одно..

Ну почему же в таком чёрном свете?

Знаешь, App-сервер можно совсем без GC реализовать.

Так что, извини, тут ты не прав...

>> Деже если предположить, что нижний уровень поднимет все такие данные в память (MS SQL, например так и сделает) , все равно остается "лишний" промежуточный слой передачи (ODBC/ADO + TCP/IP?), переоформление данных из native вида в объект.
TK>В случае с MS SQL на локальной машине использовать TCP/IP совсем не обязательно — он может использовать shared memory протокол. Скажу сразу — shared memory в сравнении с TCP/IP это не просто быстро, а очень быстро...

Но весь прочий оверхед всё равно ведь никуда не девается.

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

S>Фактически речь идет о том, что если ты пообещал Durability, тебе необходимо гарантировать, что отложенные записи не станут потерянными записями даже при application fault.

100%-ная выполнимость обещания durability может быть обеспечена только при корректной эксплуатации, что справедливо и для SQL-серверов, и для App-серверов. И вообще для любых систем с промежуточным хранением данных.

ГВ>>Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
S>Да нет конечно, вот только ACID уже встроена в СУБД, и это далось им достаточно большой кровью. У меня потеют ладони, когда я думаю о самопальной реализации ACID. Если мы получим полноценное универсальное решение для ACID за пределами RDBMS, нас станут носить на руках и цитировать в учебниках

Антон, я при случае напомню, можно?

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

ГВ>>Главная причина потери эффективности в stateless-модели состоит в том, что почти всегда в обработку вовлекается сервер базы данных, то есть этот "пирог" из клиента, app-сервера и сервера БД всегда "прорезается насквозь", и очень хочется этого избежать.
TK>Не обязательно делать простой, трехслойный пирог. Слоев может быть несколько и в итоге каждое конкретное разрезание может и не доходить да самого последнего слоя.

Ну а куда же тогда промежуточное состояние денется?

ГВ>>Это тоже в принципе верно, но для того в stateful-систему и добавляются механизмы синхронизации кэшей, хитрый арбитраж блокировок и т.п. Естественно, что мощности одной машины может и не хватить.
TK>Вот именно — хитрые механизмы синхронизации, хитрые арбитражи. т.е. можно сказать, что синоним слова statefull это хитрый.

Нет, слово "хитрый" употреблено как синоним слова "сложный".

TK>В итоге сложность и стоимость системы растет слишком не пропорционально.

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

TK>>>Ну и опять-таки поддержка работы в режиме 24x7 — для stateless это будет достаточно безболезненно, а для statefull придется отключать клиентов и т.п.
ГВ>>Откуда такое утверждение? Это совершенно необязательно.

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

А никто не говорит, что это просто, а тем более — очень просто. Это возможно и реализуемо. Разицу чуешь?

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

Увы, с этим на мировом рынке некоторая напряжёнка...

TK>>>Если использовать этот пример, то можно посмотреть на OODB. Казалось-бы уж кто лучше должен знаеть о том, как устроена объектная модель приложения. Но, где хоть один достойный пример реализации (из тех, что может посоперничать с RDBMS)?
ГВ>>Сейчас навскидку не скажу, помотри где-то cetus-links был документ из серии "XX мифов об объектных базах данных".
TK>вот и результат, единственное, что можно уверенно сказать про объектные базы данных — "навскидку не скажу и помотри где-то". Нормальной реализации нет (конечно — тут для велосипедов простор открыт)

Не, ты не понял. Как раз один из мифов и есть миф о том, что OODB не соперники реляционным. Просто я не помню, какая база там упоминалась в качестве примера. O2, что ли...

ГВ>>Ну вот, кстати, как раз та самая подмена понятий, о которой упоминал AVK. Как ты реализуешь атомарную операцию, если она растянута, к примеру, на 30 минут? На все 30 минут блокируешь данные? Нет, конечно. Ты разбиваешь её на серию более мелких, отмечающих промежуточные, т.е., недолговременные состояния системы. Таким образом, реализуется в десяток раз больше обращений к БД, чем в случае, когда промежуточное состояние хранится в памяти App-сервера и записывается только одно — последнее изменение. А в случае stateless, мы получим по сути, тот же stateful, но "под микроскопом", где из-за каждого чиха появляется серьёзная програмисткая задача.
TK>Это ты про использование BizTalk Server? Согласен, в случае со statefull стратегией — легко сорваться и начать все делать руками.

Да нет, это я только о применении коммуникационных stateless-механизмов для реализации stateful-моделей.

[skip about RSDN]

ГВ>>И с другой стороны — дерево сообщений это и есть один из типов объектов.

TK>А он точно нужен?

Ну в данном случае — только для примера.

В принципе, признаю неудачность примера, хотя... Топики тоже можно кэшировать. Но это сугубое ИМХО.

TK>>>Single-Write-Multiple-Read — для stateless это задача базы данных. Баз данных у нас опять-таки может быть несколько, и использование репликации снимет проблемы с нагрузкой на конкретный SQL сервер.
ГВ>>Угу, только с привлечением БД всё это работает намного медленнее, чем в памяти App-сервера, хотя бы как минимум в силу того, что для обращения к этому объекту задействуются драйверы БД, паковка/распаковка SQL и т.п. Не говоря уже о том, что в пределе вся бизнес-логика улетает в ХП+триггеры...

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

Ну, скажем так, она почти всегда примерно одинакова — драйвер, протокол обмена с сервером, +- компиляция SQL...

ГВ>>Да хоть груздь чешуйчатый.

Суть-то проблемы не меняется: необходимо организовать согласованную работу нескольких компьютеров.
TK>Oracle 10g. Не нужно никаких мощных серверов... просто ставим кучу машин уровня рабочей станции под линуксом.

А если не Oracle? Причины, по которым выбиратся тот или иной сервер БД ведь могут быть разными и совсем не техническими.

ГВ>>Всё зависит от того, что именно в этом кэше лежит. Если это просто записи БД, то — да, если предварительно созданные объекты, то нет.
TK>Какая-то неувязочка... есть y = f(x) x — это записи, y это объект. f какое-то фиксированное преобразование. получается, что фиксированное преобразование + сырые данные это есть состояние? А если преобразование отложить?

То получим один из случаев оптимизации stateful-модели.

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

H_D>Более того, я сделаю более сильное утверждение, чем сделаное чуть выше:
H_D>

действительно интерактивную систему принятия решений на основе актуальных данных НЕВОЗМОЖНО сделать в рамках модели стейтлесс.

Да, действительно, сильное утверждение

Только хотелось бы услышать более чёткое определение понятия "действительно". "Очень действительно" или "совсем действительно" не предлагать

H_D>На предстоящий вопрос почему сразу отвечу в виде леммы:

Вот до чего может довести хорошего человека излишнее увлечение глупыми книжками

H_D>

Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.

Что значит залезть внутрь? Речь о хаках или о преднамеренном обходе программистом ограничений модели?

H_D>

Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.

Первичная валидация данных, например. Зачем гонять на сервер строчку "bla-bla-bla", если известно, что она должна содержать маску ###-###-####?

H_D>То есть в случае, если верно (3) — стейтлесс получается не ООП, а процедурным программированием, что откатывает нас назад в развитии программирования, так как почти ничем не отличается от RDBMS

Я же говорю книжек начитался

В таком случае позволю себе крамольную цитату, всего один абзац:

...
Because the contract and schema for a given service are visible over broad ranges of both space and time, service-orientation requires that contracts and schema remain stable over time. In the general case, it is impossible to propagate changes in schema and/or contract to all parties who have ever encountered a service. For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code.
...

Code Name Indigo <br />
A Guide to Developing and Running Connected Systems with Indigo

Don Box

Это лишь одно из мест где Дон Бокс пока осторожно упоминает, что на ООП мир клином не сошёлся. Тем не менее основаная мысль вполне ясна — share schema and contracts, not class. Под это в основном и заточен Indigo.

Так что

Кто там год назад с упорством защищал C++? Пришла пора встать на защиту ООП! Вперёд!

H_D>

Вывод 2. Из (7) и (9), через (8) мы получаем, что создание интерактивных систем со всегда актуальными данными на базе стейтлесс с использованием MBR невозможно.

В общем ход твоих мыслей я уже давно потерял, но мимо этого пройти не могу, религия не позволяет

Ты в своём доказательстве забыл одну простую вещь. Для реализации подобного механизма в stateful необходимо как минимум поддерживать версию объекта, которая является частью состояния. Но ведь в stateless состояние не куда не девается, просто оно в другом месте. Если учесть что многие разработчики используют в различных целях поля типа LastModifiedDateTime, то такой атрибут версионности у нас уже часто есть. Если нет, то его не лишним будет добавить наряду с LastModifiedUserID. В таком случае, то о чём ты говоришь реализуется элементарно с помощью следующего запроса:

UPDATE
    Whatever
SET
    ...,
    LastModifiedDateTime = getdate()    
WHERE
    ... AND
    LastModifiedDateTime = @LastModifiedDateTime

Далее либо прямо в SQL сервере, либо в бизнеслогике достаточно проверить число сохранённых записей и если оно равно 0, то кидаем исключение. В результате имеем — кто первый встал того и тапки. При этом, заметь, практически никакого оверхеда.

H_D>

Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели.
H_D>

Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс.

На будущее, мой тебе совет. Никогда не делай категорических выводов

H_D>Итак, окончательный вывод: невозможно построение систем интерактивного принятия решений на основе только стейтлес модели.

Ну всё, хватит меня смешить

H_D>стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть :

Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят. Объекты же, которые можно рассматривать как аналоги полноценных объектов в stateful, пролетают через апп-сервер со свистом в обоих направлениях и долго там не задерживаются. Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества

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

IT>>Оптимизаторы запросов реляционных БД шлифуются уже десятилетиями. Писать же выборку по двум-трём связанным бизнес сущностям в памяти ты будешь сам во время отведённое тебе на разработку. Оптимизировать этот запрос ты тоже будешь сам.

ГВ>Во время, отведённое мне на разработку чего?

А оптимизация... Не так страшен чёрт, как...

Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы. Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.

IT>>Кешь и стэйтфул — это далеко не одно и тоже. Мне не нужно синхронизировать каждый объект и мне не нужно сложных механизмов для этого. Кеширование справочников и сброс кеша при изменении в БД пишется на коленке. А если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту, ...

ГВ>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?

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

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

IT>>Не забудь так же обновить все мапы, которых коснётся уменьшение зарплаты Петрову за прогулы.

ГВ>Если нужно будет — то почему и не обновить? Кстати, ещё один вопрос: как соотносится время выполнения std::map::insert() со временем INSERT INTO?

А при чём тут это. Тебе второй insert тоже делать надо, а вот мне первый совсем не обязательно

IT>>И когда будешь обновлять мапы не забудь залочить свой app-сервер во избежании undefined behaviour.

ГВ>Э-э-э... знаешь ли... мапы тоже могут быть версионными.

Ах у вас ещё и мапы версионные. Ну тогда гуд лак

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

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

Э-э-э... с компасом видимо что-то не того.

AVK>>Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе.
IT>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок

Широкий простор для совершения ошибок обычно открывается кривыми руками.

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

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

ГВ>Э-э-э... с компасом видимо что-то не того.

Зато теперь он у меня показывает исключительно в правильном направлении, чего и Вашему желаю

AVK>>>Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе.
IT>>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок

ГВ>Широкий простор для совершения ошибок обычно открывается кривыми руками.

Это само собой. Просто stateful это хорошая питательная среда для выращивания крупномасштабных глюков. Так что кривые руки + stateful... просто страшно подумать что может получиться.

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

[...]

IT>Так что

IT>Кто там год назад с упорством защищал C++? Пришла пора встать на защиту ООП! Вперёд!

Да, пожалуй я перестану активно защищать C++. У Microsoft это гораздо лучше получается.

Ну что же, как показывает практика, осталось подождать, пока MS начнёт защищать ООП.

[...]

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

Уффф... ну наконец-то...

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

ГВ>>[...] Например, приходится обеспечивать эквивалентность поведения объектов (методов!) совершенно разными средствами: в одном случае это какой-нить JScript, в другом — VBScript, в третьем — C++/C#, в четвёртом — T-SQL. И всё это должно работать адекватно (чёрт с ней с синхронностью, о ней даже вспоминать при таких раскладах страшно). Здорово? ИМХО — нет. Хотя бы потому, что у этих средств совершенно разные возможности и назначения.
TK>Бред. Есть единая среда .NET и тот-же C# будет использоваться как на клиенте, как на промежуточных серверах, так и в базе данных. Зачем делать сборную солянку из разных технологий?

Вот и я думаю — с чего это к примеру JavaScript-ы RSDN.ru не используют .Net framework?

Может, объяснит кто?..

ГВ>>Идём дальше. Создали объекты в промежуточной БД. Что они отражают? Ответ: они отражают временное промежуточное состояние. Т.е., это и есть реализация stateful. Притом совсем как "клапана через выхлопную трубу", вернее — "RAM средствами SQL-сервера".

Дорассуждались-таки.

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

Хммм.. Не путай калий с кальцием. Промежуточное состояние потому и называется промежуточным, что оно как минимум не подчиняется требованиям целостности, предъявляемым к данным системы в целом и существует исключительно как реализация технического приёма. Отсюда "атомарность" означает всего лишь то, что переход из одного промежуточного состояния в другое будет окружён BEGIN TRANSACTION и COMMIT TRANSACTION. Т.е., технически, для сервера базы данных, это атомарная операция, но для базы данных, как совокупности данных, используемых в долговременной перспективе и ограниченных правилами контроля целостности её попросту нет, поскольку состояние сие системой до поры до времени должно игнорироваться. Следовательно, для выполнения транзакции, результаты которой будут значимы для системы, нам нужно провести ряд таких операций. Получаем два вопроса: 1. Что делать с откатами (мы ведь уже сделали commit!)?, 2. Зачем задействовать для хранения СУБД в тех случаях, когда интервал между первой и последней технической транзакцией позволяет хранить данные в памяти App-сервера?

TK>>>Хочет редактировать — пожалуйста. Все подчиненные документы помечаются как не проведенные, и дальше редактируются как обычно — в stateless манере. Причем все это даже в offline — мобильный менеджер не имея постоянной связи с офисом сможет на месте у клиента легко оформить заказ, запланировать собрание, встречу. А когда появится соединение — все эти данные будут синхронизированы с основной БД.
ГВ>>Проблема совсем не в этом, а в том, что нужно развешивать груду разнообразных флагов в клиентском коде для того, чтобы отследить контекст, в котором выполняются транзакции завершения подчинённых документов. Здесь получается одно из двух: либо ты ты пишешь две разные процедуры выполнения
TK>Что за флаги? Проще надо быть...

Ну да... ещё можно две разных реализации откатов сделать. Это же тоже очень просто.

ГВ>>Мммм... ИМХО, бизнес код, это всё-таки кодирование некоторой абстракции предметной области, а уж коль скоро мы обсуждаем здесь ОО-модели, то и бизнес-код, это всё-таки объекты, следовательно — состояния + методы. Так что, ты не прав...
TK>Ну, возьмем произвольный бизнес процесс. Пусть это будет процесс приема нового сотрудника. Для stateless реализации — нам нужно получить документ (например XML файл) описывающий этого сотрудника создать запись в учетной системе, написать письмо для выдачи пропуска, выполнить еще какие-то операции. Где здесь объектность данного процесса?

Исключительно в мозгах разработчика. Например:

1. Создание учётной записи — это главное, все прочие операции можно и продублировать.
2. Отстрел представлений (т.е., разновидностей репрезентаций) в виде:
— документа-описания (к примеру — учётной карточки);
— письма для выдачи пропуска.

Операции пункта 2 скорее всего запрашиваются сразу по окончании операции 1 и могут быть немедленно продублированы, так что мы задержим объект в кэше. А надо или не надо задерживать запись — трудно сказать.

Замечание: Хотя, конечно, сам вопрос поставлен — обхохочешься.

Объектность (декомпозиция, взаимодействие и т.п.) — это всего лишь способ структурирования человеком некоторого обмена информацией между программами компьютеров, которые обслуживают некоторый "бизнес-процесс", а по-русски — предметную область. Притом реализация может быть как объектной, так хоть и на калькуляторе MK-52 с подключённым принтером. C точки зрения данного процесса у него нету ну никакой "объектности".

TK>>>С тем-же успехом, можно написать достаточно универсальное хранилище, для управления состояними и откатом.
ГВ>>С тем же, это с каким?

TK>Да что писать... возьмем biztalk — и бизнес логика и управление состоянием текущего бизнес процесса и при необходимости откат. И если посмотрим на реализацию — это не классический app сервер который тупо хостить наборы объектов.

Новое обобщение. Это ещё откуда? Знаешь, мне подобные обобщения иногда напоминает что-то вроде: "Ну как мы все знаем, американцы никогда на самом деле не были на Луне..." и дальше длинные ругательные рассуждения, на основании этой "посылки". Извини, не обижайся. Просто постарайся повнимательнее обходиться с таими эпитетами. Знаешь, SQL-сервер тоже всего лишь тупо хранит данные на диске.

ГВ>>Почему? Фиксация промежуточных состояний применяется совсем независимо от выбранной "парадигмы" — stateless или stateful. Это как минимум один из способов обеспечения надёжности. Состояния можно сбрасывать, а можно и не сбрасывать. Просто если мы реализуем stateful-модель в памяти App-сервера, то фиксация промежуточных состояний механизмами долговременного хранения информации — порой полезная, но в целом совсем не обязательная фича.
TK>Правильно, только для stateless реализации мы имеем дело с завершенными состояниями объекта.

Ни о каких "завершённых" состояниях не может идти и речи, если есть длинная транзакция. Можно говорить только о завершении транзакций сугубо "технического" значения.

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

Зато есть проблема перегонки связанных документов и справочников.

ГВ>>Слова одни и те же, но означают совершенно разные вещи. Я тебе всё-таки ещё раз скажу: замерь для интереса время выполнения сопоставимых операций на SQL-сервере и в памяти App-сервера в совокупности со временем доступа к их результатам.
TK>App сервер данные тоже не из воздуха берет, а из того-же SQL сервера. А про оптимальность доставания данных из SQL и из памяти апп сервера уже говорили. Все эти объектные запросы — очень плохо оптимизируются. (например, нужно достать всех клиентов, которые делали за прошлый месяц заказы продукта X) И что? Так-же не забываем — что в случае с app сервером нам нужно держать в памяти не только текущий экземпляр объекта, но и его копию (мы-же не хотим, что-бы один пользователь увидел то, что редактирует другой)

Нет, объектные запросы выполняются не только в памяти App-сервера. Как раз для аналитики пока что лучше подходят механизмы SQL-серверов.

ГВ>>Ну и что получается? Вместо хранения состояний в памяти заводим для них отдельную БД? Супер! Разница во времени доступа исчисляется порядками: наносекунды против, в лучшем случае — десятков микросекунд.

Мда-а... оптимизация, ничего не скажешь.

TK>У вас, что inprocess app сервер с отложенной записью (оригинальная конструкция. название у этого сервера есть)? Раз уж наносекунды получаются... Не стоит забывать, что количество обращений для к серверу для statefull и stateless случаев разное.

В данном случае я сравнивал время доступа App-серверного кода к данным, реализующим состояния объектов во вполне конкретном прикладном случае.

TK>>>Все таки кластер — это ближе к statefull модели для которой тесная интеграция более естественна. stateless будет ближе к слобо связанным grid системам.
ГВ>>И к обеспечению ещё большей нагрузки на каналы. Оптимизация, млин.

А слабосвязанными прекрасно могут быть и stateful-системы. Это вообще вопрос отдельный.

TK>Давайте не будем про нагрузку на каналы... Для stateless — количество обращение на много меньше. так что она может оказаться примерно одинаковой.

Да, именно что может. Здесь, конечно, не столько stateless/stateful-ность определяют трафик, сколько прямота рук архитектора.

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

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

ГВ>Уффф... ну наконец-то...

А разве кто-то из апологетов stateless когда-то это отрицал? Обратное утверждают и пытаются это доказать как раз сторонники stateful.

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

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

Ну вобщем — да. Мы же и не север ищем.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Зато теперь он у меня показывает исключительно в правильном направлении, чего и Вашему желаю

ГВ>Ну вобщем — да. Мы же и не север ищем.

Простите, а что я сказал смешного?

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

IT>>>Ты в своём доказательстве забыл одну простую вещь. Для реализации подобного механизма в stateful необходимо как минимум поддерживать версию объекта, которая является частью состояния. Но ведь в stateless состояние не куда не девается, просто оно в другом месте.
ГВ>>Уффф... ну наконец-то...

IT>А разве кто-то из апологетов stateless когда-то это отрицал? Обратное утверждают и пытаются это доказать как раз сторонники stateful.
На самом деле из-за терминологии ещё некоторая путаница появляется. Суть в том, что не хочется по любому поводу привязываться к SQL-серверу, только и всего. Неудобно по ряду причин сие есть с точки зрения некоторых, к которым себя и причисляю.

... << RSDN@Home 1.1.2 beta 2 >>

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

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

IT>>>Оптимизаторы запросов реляционных БД шлифуются уже десятилетиями. Писать же выборку по двум-трём связанным бизнес сущностям в памяти ты будешь сам во время отведённое тебе на разработку. Оптимизировать этот запрос ты тоже будешь сам.

ГВ>>Во время, отведённое мне на разработку чего?

А оптимизация... Не так страшен чёрт, как...

IT>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы.

А... это, в разработку системы вполне может быть включена разработка соответствующих stateful-сервисов.

IT>Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.

Ещё одно обобщение... а, ладно. Достался я уже.

IT>>>Кешь и стэйтфул — это далеко не одно и тоже. Мне не нужно синхронизировать каждый объект и мне не нужно сложных механизмов для этого. Кеширование справочников и сброс кеша при изменении в БД пишется на коленке. А если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту, ...

ГВ>>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?

Вернусь к этому моему ответу. Я здесь несколько поспешно подумал, что речь только о пользователе. Просто в случае App-сервера клиентом является бизнес-код.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>>Не забудь так же обновить все мапы, которых коснётся уменьшение зарплаты Петрову за прогулы.
ГВ>>Если нужно будет — то почему и не обновить? Кстати, ещё один вопрос: как соотносится время выполнения std::map::insert() со временем INSERT INTO?

IT>А при чём тут это. Тебе второй insert тоже делать надо, а вот мне первый совсем не обязательно

Ну... зато мне JOIN делать не обязательно.

IT>>>И когда будешь обновлять мапы не забудь залочить свой app-сервер во избежании undefined behaviour.
ГВ>>Э-э-э... знаешь ли... мапы тоже могут быть версионными.
IT>Ах у вас ещё и мапы версионные. Ну тогда гуд лак

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>На самом деле из-за терминологии ещё некоторая путаница появляется. Суть в том, что не хочется по любому поводу привязываться к SQL-серверу, только и всего. Неудобно по ряду причин сие есть с точки зрения некоторых, к которым себя и причисляю.

Если не привязываться к SQL серверу, то путь только один — изобрести свой

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

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

IT>>>Зато теперь он у меня показывает исключительно в правильном направлении, чего и Вашему желаю

ГВ>>Ну вобщем — да. Мы же и не север ищем.

IT>Простите, а что я сказал смешного?

Меня просто всегда такие аллегории забавляют.

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

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

ГВ>>На самом деле из-за терминологии ещё некоторая путаница появляется. Суть в том, что не хочется по любому поводу привязываться к SQL-серверу, только и всего. Неудобно по ряду причин сие есть с точки зрения некоторых, к которым себя и причисляю.

IT>Если не привязываться к SQL серверу, то путь только один — изобрести свой

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

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

IT>>Простите, а что я сказал смешного?

ГВ>Меня просто всегда такие аллегории забавляют.

Я так и подумал.

Смотрю я на эту ветку и думаю, когда же, наконец, начнут обсуждение реализации stateful-модели в J2EE/EJB-сервере(рах) приложений. Видимо, не дождусь... ;(

MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно. И здесь, видимо, собрались практики и знатоки именно технологий от MS (BizTalk, например, упоминается очень часто), а альтернативы нету.

Что скажете? Интересно было бы послушать альтернативщиков платформы MS, прежде всего из стана Java.

Hello, "Геннадий Васильев"
>
> Новое обобщение. Это ещё откуда? Знаешь, мне подобные обобщения иногда напоминает что-то вроде: "Ну как мы все знаем, американцы никогда на самом деле не были на Луне..." и дальше длинные ругательные рассуждения, на основании этой "посылки". Извини, не обижайся. Просто постарайся повнимательнее обходиться с таими эпитетами. Знаешь, SQL-сервер тоже всего лишь тупо хранит данные на диске.
>

Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью). Вобщем — хотелось-бы видеть конкретные продукты и приимеры реализации. Может тогда и вопросы сами собой отпадут?
Вот например сервер без GC. Замечательно — давайте рассмотрим stateless vs COM+ и реализация бизнес объектов на С++?

Posted via RSDN NNTP Server 1.8 beta

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

TK>Что, если мы пишем метод который в рамках одной транзакции пишет => читает => обновляет то это уже не stateless метод?

Если транзакция распространяется на несколько методов то уже не стейтлес, ибо транзакция суть состояние.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Вот только когда в пределах одной транзакции у тебя несколько обращений к серверу для модификации это уже как бы не совсем стейтлес

.
M>А зачем несколько?

Затем что надо

M>Можно прогнать всю транзакцию и за одно обращение.

Примеры того когда это невозможно я уже приводил.

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью).

Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят? Да собственно и СОМ+ отнюдь не ограничивает разработчика определенной моделью.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>А зачем его тянуть по маленькому кусочку? Обычно при работе происходит следующее — мы тянем некий первичный документ. Его можно тянуть сразу целиком, в стейтлес манере, забив на ООП.

IT>Вот что и требовалось доказать

Да я собственно изначально об этом говорил.

AVK>>Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?

IT>Дать ему уникальный guid при создании.

Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.

IT>Откуда сделан такой вывод?

А вот предложения ТК и твои лучшим образом это подтвердили. И он и ты постоянно предлагаете мне править прикладной код для решения задачи управления.

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

Я? Я пока что ничего не решаю. Я собственно и решения то не предлагал никакого.

IT>Возьми BizTalk и не мучайся (правда он стоит зараза),

Отож.

IT> переписывать бизнес-правила тебе не придётся. Только перерисовывать

Это уже детали. Впрочем в данном конкретном случае может оно и прокатит. Не зальешь дистрибутив на сервер?

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

IT>Ты делаешь свою систему как коробочный продукт или на заказ/для своей конторы?

Черт его знает. Пока точно не известно. Вероятность того что это будет коробка не нулевая. Даже если это будет внутренний продукт совершенно точно его будут пользовать внедрюки в различных филиалах.

IT>Твоя задача не изобрести ещё один BizTalk, а максимально быстро и с наименьшими затратами решить поставленную задачу.

Спасибо что разъяснил

. А бизтолк не катит, его стоимость для конечного решения будет дороже того за что можно наш продукт продать

.

AVK>>Ну вот о том и речь что стейтлес модель просто перекладывает свои проблемы на плечи бизнес-программиста.

IT>Это тут при чём? Или у стэйтфул программистов есть секретарши, которым они надиктовывают свой код?

Нет, у них есть сервер приложений.

IT>Код то всё равно писать

Код управления состояниями?

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

IT>Ничего оно не ограничивает. А совсем наоборот. Благодаря простоте реализации stateless оставляет больше времени, чтобы бегать по этим просторам.

Ну да, вроде хранения состояния в БД всегда, даже если его хранить то надо десяток секунд.

AVK>>Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.

IT>Ну и как это противоречит stateless модели?

У ней состояния нет, оптимизировать нечего

.

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

AVK>>Хороши усилия — после каждого запроса скидывать состояние в БД

IT>Подожди, подожди. А разве у тебя состояние объектов может не соответствовать их состоянию в БД?

В незакрытой транзакции? Может конечно, иначе ради чего огород городить?

IT>>>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию

, давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.

AVK>>Зря.

IT>Зря что не отличаются?

Зря что давно не был

Зря сомневаешься конечно.

AVK>>Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.

IT>Порядки начисления — это бизнес логика.

А кто спорит. Просто необходимость непрерывно переписывать бизнес-логику начисления приводит к возрастанию фактора простоты написания этой бизнес-логики. Ты думаешь почему у 1С предприятия практичеси полное доминирование на рынках малых и средних предприятий? А вот в Америке почему то подобных решений не замечено.

IT>>>Слова мужа

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

AVK>>Слова Стива Шварца помнишь?

IT>Какие именно

Те самые, которые я процитировал в самом начале.

IT>>>Возможно. Насочинять можно много чего.

AVK>>Ну он вроде как говорил где именно та или иная схемка реализована на практике.

IT>На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.

Напиши ему.

AVK>>Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе.

IT>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок

Так идея то в том чтобы это реализовать один раз, а не каждый раз когда нужна новая бизнес-логика.

AVK>> Кроме того не следует пытаться надуть муху до размеров слона. Если начинали с решения для малых предприятий пытаться потом получить из этого кластерного монстра неразумно.

IT>Ты так думаешь потому что тебе это просто пока не приходилось делать

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

AVK>>Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.

IT>Что-то я тут опять мало что понял. Закладвать в архитектуру расширяемость можно и нужно всегда.

Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Это само собой. Просто stateful это хорошая питательная среда для выращивания крупномасштабных глюков. Так что кривые руки + stateful... просто страшно подумать что может получиться.

Кто бы спорил. Создание серверов приложений было и пока что есть одна из самых сложных задач.

... << RSDN@Home 1.1.2 beta 2 >>

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

Tom>попробуй выполнить и прочувствовать разницу.
Tom>у меня профайлер сказал:
Tom>M1 — 4,290

Запятая это десятичная или просто отделение порядка?

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы. Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.

А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.

ГВ>>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?

IT>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.

Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.

... << RSDN@Home 1.1.2 beta 2 >>

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

M>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.

С чего бы это? Вместе с промежуточными состояниями при отключении электричества навернутся и все незакоммиченые изменения. Это sql сервер, поскольку вносит изменения сразу на диск, вынужден поддерживать персистентный же лог транзакций.

... << RSDN@Home 1.1.2 beta 2 >>

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

M>Что значит "типа"? одно из свойств ACID, а именно D, подразумевает, что если транзакция зафиксировалась, то откатить ее уже нельзя никаким образом. Вообще. Как ты ее собираешься в памяти фиксировать?

А какой смысл фиксировать транзакцию в памяти?

M>Ок, эксепшена не произошло, сказали commit, чего делаем?

Пишем в БД разумеется.

M>А она у тебя по прежнему в оперативке, как я понял.

Неправильно ты понял.

... << RSDN@Home 1.1.2 beta 2 >>

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

H_D>самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то)

Наверное потому что сжатие лога, если этот лог на диске, очень дорогая операция.

H_D>+1 плюс к тому же, можно в памяти хранить часть особо часто используемых индексов — это даст возможность еще больше разгрузить компьютер, так как на текущий момент самое узкое место всех AppServer'ов да и вообще серверов — это дисковая система.

Я бы сказал немножко более обще — подсистема хранения и доступа к данным.

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>>Что, если мы пишем метод который в рамках одной транзакции пишет => читает => обновляет то это уже не stateless метод?

AVK>Если транзакция распространяется на несколько методов то уже не стейтлес, ибо транзакция суть состояние.

Это уже не состояние, а демагогия. С тем-же успехом можно сказать, что транзакция это процесс перехода из одного устойчивого состояния в другое устойчивое состояние. А учитывая, что две разных транзакции изолированы друг от друга — можно сказать, внутрее состояние транзакции является неопределенной величиной для стороннего наблюдателя. Так что-же это за состояние, которое нельзя ни измерить, ни увидеть?

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

ГВ>100%-ная выполнимость обещания durability может быть обеспечена только при корректной эксплуатации, что справедливо и для SQL-серверов, и для App-серверов. И вообще для любых систем с промежуточным хранением данных.
СУБД обеспечивает 100% durability при сколь угодно не корректной работе, если при этом носитель физически в порядке. Причем он делает это автоматически при любых сбоях.
А если еще и DBA с прямыми руками, то даже физическая порча диска не страшна. И вместо того, чтобы добиваться такого эффекта в рукопашную, можно направить кипучую энергию в каком-нибудь более полезном направлении..

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

AVK>А какой смысл фиксировать транзакцию в памяти?
А это не я придумал..

M>>А она у тебя по прежнему в оперативке, как я понял.
AVK>Неправильно ты понял.
Ну почитай сообщение ГВ с которого все началось. Он-то как раз пропагандирует отложенную запись в БД, то есть фактически фиксацию в памяти..

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

H_D>>

Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.

IT>Что значит залезть внутрь? Речь о хаках или о преднамеренном обходе программистом ограничений модели?

Речь идет о потенциальной ненадежности выполнения кода на клиенте. Причем необязательно это чей то умысел. Может просто взглюкнуть комп.

H_D>>

Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.

IT>Первичная валидация данных, например. Зачем гонять на сервер строчку "bla-bla-bla", если известно, что она должна содержать маску ###-###-####?

Но при этом проверку обязательно нужно повторить на сервере.

IT>For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces.

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

IT>Don Box

Это тот самый, который хочет коммуникацию между доменами через soap делать?

IT>Это лишь одно из мест где Дон Бокс пока осторожно упоминает, что на ООП мир клином не сошёлся.

Нифига себе осторожно! Если читать не тех. документацию, а маркетинговые реляции так МС уже вовсю провозгласил отказ от ООП. Тока провозглашать можно еще долго, но пока .NET еще не стал просто средством написания веб сервисов.

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

Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.

IT> Тем не менее основаная мысль вполне ясна — share schema and contracts, not class. Под это в основном и заточен Indigo.

Поправочка — Indigo Application Services, но не Indigo Remote Objects.

IT>Так что

IT>Кто там год назад с упорством защищал C++? Пришла пора встать на защиту ООП! Вперёд!

Это H_D то С++ защищал? Текс, H_D, признавайся, это под каким же ты ником мог позволить себе подобные безобразия?

IT>Хана твоему ООП. Сегодня рулят схемы и контракты

Пока что только на бумаге.

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

Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.

IT>Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества

Опять ты в крайности ударяешься

... << RSDN@Home 1.1.2 beta 2 >>

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

ZEN>MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно.

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

... << RSDN@Home 1.1.2 beta 2 >>

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

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

ZEN>>MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно.

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

Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом

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

M>>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.

AVK>С чего бы это? Вместе с промежуточными состояниями при отключении электричества навернутся и все незакоммиченые изменения.
Правильно. Но по сценарию ГВ, с отложенной записью в БД, и закоммиченые тоже, поэтому durability и идет лесом.

AVK>Это sql сервер, поскольку вносит изменения сразу на диск, вынужден поддерживать персистентный же лог транзакций.
Вот здесь есть нюансы.
Систем журналирования может быть несколько, а именно UNDO, REDO, UNDO/REDO, NO UNDO/NO REDO.
Самыми эффективными, в большинстве случаев, как показывает практика, являются системы с undo/redo журналированием, то, что ты называешь "вынужден поддерживать персистентный же лог транзакций".
Если же применяется UNDO схема — все не зафиксированные изменения держатся в памяти, то в силу того, что незафиксированых изменений, при большой нагрузке, может быть довольно много, будет происходить перерасход памяти.
То есть сервер вносит изменения на диск, потому что в большинстве случаев так выгоднее.

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

TK>Не надо так утрировать. Документы отправляемые на сервер могут содержать достаточно много информации, что-бы считать веб метод обычной процедурой.

Не понял. У нас уже что — ООП от неООП отличается количеством информации, отправляемой на сервер? Странный подход.

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>В случае с MS SQL на локальной машине использовать TCP/IP совсем не обязательно — он может использовать shared memory протокол. Скажу сразу — shared memory в сравнении с TCP/IP это не просто быстро, а очень быстро...

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

TK>Никто особенно не возражает, но не забываем, что у веб сервиса все таки есть какой никакой контекст.

Если использовать контекст, то это уже стейтфул модель, причем особо извращенным способом

... << RSDN@Home 1.1.2 beta 2 >>

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

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

В>Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом

С весенними ручьями он слился

Вобщем утекает COM+ (да и COM вообще) как песок через пальцы...

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

>>

Предположение 1. Если режим == стейтлесс и используются Serializable объекты на стороне клиента, значит из (1) и (2) вся работа, связаная с бизнес логикой выполняется через вызовы Serviced объекта (т.е. по сути вызов процедур сервера).

TK>Не совсем так... Не зря пртокол назвается SOAP и Web метод тоже не спроста.
Сорри не верно выразился... Serviced объект — это как раз имеется в виду WebService.

>>

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

TK>Ну, самый простой бизнес процес из нашей, так сказать, жизни.
TK>Вот собрался Синклер приехать к нам 15-го на встречу, ну и пообщаться тоже. На работе ему это оформляют под это дело командировку, дают командировочные, когда приедет — устроится в гостинницу (может и нет — смотря по реализации), потом мы сходим в Ms, посидим там, дальше поедем пить пиво, купим пиццы и т.п. (кстати — предположим ему компания оплачивает только две пиццы, а купили 3), дальше пиво допили, разъехались, Синклер вернулся домой, отчитался за командировочные (а может и нет — ну, потерял бумажки) и на этом процесс завершился. Все предельно просто.

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

Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.

TK>Не надо так утрировать. Документы отправляемые на сервер могут содержать достаточно много информации, что-бы считать веб метод обычной процедурой.
Тем не менее... какая разница? мы посылаем ДАННЫЕ вместо того, чтобы вызвать метод бизнес объекта.. значит — процедурный подход (где-то в соседней ветке было про всеобщее заблуждение по поводу ООП/Не ООП)
>>

Предположение 2. Пусть режим стейтлесс и используется не Serializable объекты, а MBR.

TK>А зачем использовать стейтлесс и MBR? Или это доказательство по индукции (типа так полохо, так тоже плохо — значит по любому плохо)?
В точку!

>>

Утверждение 3. из (6) мы получаем ровно две стратегии для соблюдения атомарности изменений:
>>

Стратегия № 1 ( известная как pessimistic locking + Repeatable Read): Мы должны блокировать объект, к которому кто-то получил доступ. Иначе, при начале изменений этим кем-то, все, кто уже получили тот же объект на чтение, будут иметь неактуальные (частичные) данные. В данной стратегии развития, мы получаем, что один человек, взявший в работу объект, не дает работать всем, кому этот объект нужен зачем-либо, пусть даже для join'ов.

TK>Ну это уже прошлый век. Никто так давно не делает...
Ну ты не прав... некоторым нужно делать именно так... кстати, если отвлечься от именно БД AppServer'ов и прочего — очень многие процессы внутри винды так и делают... да и поезда на перегонах ЖД таки стоят и ждут пока перегон (или сколько там? 2, 3, 4 ??? ) не освободится. Причем, вполне возможно, что один поезд уже проехал место, где должен остановиться второй. но второй все равно ждет (pessimistic locking в действии!)

>>

стратегия №2 (на самом деле — их три, близких по смыслу, известных как Versioning, Read Commited, optimistic locking ) либо делать "скрытое копирование" (Versioning, Read Commited) с блокировкой на изменение объекта (Read Commited) или же просто блокировать объект с "отстрелом всех активных "читателей" (optimistic locking) при начале изменений объекта либо при начале транзакции.

TK>А зачем делать копирование, если и так используется stateless? Точно от противного...
MBR и не надо копировать??? ты что, на каждого клиента по копии держать бкдешь??? тогда это уже стейтфул — сервер знает, в чьем контексте какой объект..

так что — копирование on-demand.

>>

Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.

TK>ты еще бы сказал про проблему версионников "кто последний тот и папа" — так вот, проблема эта от разврата. Делать надо все честно и по совести, если один успел, то все остальные желающие — даже и не суются и спокойно идут лесом. Либо синхронизирую свои данные до полной адекватности и повторяют попытку.
Ага! вот оно — таки pessimistic locking, а говоришь — никто не пользуется...
нет батенька, либо optimistic locking, либо pessimistic. без локов — не обойтись.
А реализовать все по схеме IT просто не выйдет — неверно это (вот если я хочу изменить только одно свойство, а кто-то в то же время другое — как это рулить в стейтлесс.

>>

Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели.
>>

Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс.
>> [/list]

TK>Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать.
Да ну? КАК ты добъешься актуальности данных в стейтлесс? будешь постоянно сдергивать с сервера "изменения за период времени"?? так это же твою сеть положит...
а сервер оповещать не сможет... он же стейтлесс — даже если он знает сколько у него клиентов — он что на каждый чих будет оповещать ВСЕХ???
а если их 100 000?
>> стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть :
>>

>>
>>
мы взяли из "неизменного" источника товар
>>
ввели количество
>>
возможно исправили цену
>>
Послали запрос и или получили success либо отопнуты по какой-либо причине (например — нет нужного количества товара
>>

>>

TK>Это совсем простая схема. В реальности — все на много сложнее.
Тем не менее — на таких задачах стейтлесс воистину рулит... стейтфул тут неудобнее.

>> TK>А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи?
>> А может их нет потому, что просто никому не пришло в голову их делать, так как "не модно"?

>>
TK>так-же как и транзакции в памяти (зато быстро).

Транзакции в памяти... расплывчатое понятие... пояснишь?

Вот у меня есть некоторое понимание э-э-э..."транзакций в памяти" — оно вполне кислотно... расскажи, про что ТЫ говоришь...

>> TK>Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу...
>> Да... возможно, но вот актуальность инофрмации в таком случае обеспечивать тем труднее, чем проще переход на оффлайн.

TK>Какие трудности видишь?
те же что уже писал — как добиться актуальности данных на клиенте, если у нас стейтлесс?.

>> >> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то.
>>
>> TK>Причем, все это время, данные будут сидеть в памяти app сервера. В то время как, stateless сервер уже давно обслуживать новые запросы,
>> Читай выше, почему такая стратегия не жизненна в любом месте, где нужна строгость в соблюдении точности и актуальности данных.

TK>строгость в соблюдении точности и актуальности данных плохо согласуются с ручным / полу ручным вводом накладных. Так-же ничто не мешает и stateless делать все необходимые проверки.
А в стейтфул тебе НИЧЕГО делать не надо — сервер сам все сделает.

>> TK>SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает...
>> Да ну? они даже без потерь питания бывают... вот например есть диск, на котором лог файл.. пусть на этом диске есть всего 100 МБ свободного места если совершить достаточно длинную транзакцию — вся БД падает, причем — невосстановимо. самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то) а при отложеном до конца транзакции сбросе данных в БД места под лог вполне может хватить — все это случай из моего опфта... в транзакции было всего лишь 65000 объектов.

TK>В stateless у тебя вряд-ли будет задейтвованно такое количество объектов... все ориентированно именно на короткую работу.
то есть если мне нужно либо импортировать справочник товаров, либо не импортировать, НО ИМЕННО весь — все, стейтлесс отдыхает, да?

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

TK>Ну, имитацию БД в рамках App сервера мы уже обсуждали...
Кто сказал про имитацию БД? я не предлагаю ЗАМЕНИТЬ БД или отказаться от БД...
я всего лишь говорю, что есть случаи, когди индексы в памяти настолько рулят, насколько никогда не рулили индексы в БД.

>> Да? насчет отложеных загрузок — я уже как-то приводил пример с графом объектов.
>> представь себе, что объекты собраны в граф... нет, пусть будет дерево. в дереве — примерно ну например 64К объектов (совершенно реальная цифра — речь идет о справочнике товаров.
>> Если мы берем вариант совсем без отложеной загрузки, то:
>>

Либо мы утягиваем с сервера, при любом неосторожно запросе, весь граф объектов (а нам-то нужен был только один).
>>

TK>Вобщем — что-бы использовать stateless стоит пересмотреть архитектуру.
А ее нельзя пересматривать... либо мы имеем удобство разработки, то есть разработчик конечного приложения пишет что-т отипа:

float Общая_Масса
Группа_Товаров группа = (Группа_Товаров)Server.Select(typeof(Группа_Товаров), /* условие*/);
foreach ( Товар товар in группа.Товары )
{
    Общая_Масса += товар.Остаток * товар.Вес;
}

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

И даже если знает, ему что — тащить на клиент всю картотеку?
Нет. Тогда надо либо делать специальную сущность ОстатокПоСкладу, либо же писать запрос к БД, который возвратит сумму в виде double, что опять неудобно — мы же говорим о работе в режиме ООП! В случае стейтфул можно в метаданных декларативно прописать, что вот этот самы Остаток есть SUM(balance) во всех карточек этого склада, для этого товара и AppServer спокойно выполнит этот запрос и вернет АКТУАЛЬНУЮ информацию, а не информацию на момент загрузки объекта в память клиента.

>> TK>С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям.
>> Далеко не все. Проверено.
>> Например — как в нем нормально хранить счетные данные типа вот такого:
>>

у нас есть дерево и на каждом кровне нам нужно иметь в узле статистику по поддереву, которая считается рекрсивно.
>> Я думаю, что через известное отверстие даже такой случай можно будет разрулить с помощью indexed view, но какой ценой??? И сколько будет стоить изменение какой-либо части алгоритма?
>> В AppServer'е, использующем собственные (хранимые) индексы можно хранить даже такую экзотическую вещь.

TK>При желании — я в БД так-же могу построить индекс и по дереву. В чем приемущество AppServer который будет его каждый раз грузить на себя все данные и перестраивать индекс не ясно...
а зачем все данные??? что мешает пользоваться механизмом кеширования страниц подобным тому, который есть в MSSQL... и хранить эти страницы... да-да именно как коре бизнес объекты

>> TK>"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения...
>> Ну не совсем.. часть данных, которые есть в AppServer'е могут быть, например, показаниями датчиков.. снимаемые в реальном времени. и ты об этом даже не узнаешь, так как они НИЧЕМ не отличаются от "обычных" бизнес объектов.
>>

TK>Каждый датчик так-же может не отличаться от обчной stateless службы.
Ага, только его придется постоянно опрашивать клиенту, у в стейтфул сервер может оповестить заинтересованых клиентов о том, что значение поменялось.

>> А так — можно будет во многих случаях обойтись без этих специальных людий и посадить только одного такого Гуру (с большой буквы) который напишеть модуль O-R mapping'а и все.
>>

TK>Вот читал форум по java — там до сих пор нормальные реализации O/R мапперов ищут. Так-же не забывай, что материализация объектов это тоже не самая быстрая операция.
Да, знаю... только в сетйтлес она происходит ну никак не реже, чем в стейтфул.. скорее — даже чаще.

>> правильно.. при увеличении производительности сервера цена сперва растет логарифмически, потом — экспоненциально (второе — совсем недолго) но в результате рост получается ниже линейного. Говорю как краеевед — я иногда железяками торгую, так что стараюсь быть в курсе.

TK>Что-же тогда google мега кластер не забабахали?
ну кто его знает

>> >>
>> Да только вот незадача — как уже писалось выше

ну не подходит стейтлес для интерактивных приложений...

>>

TK>Это на твой взгляд

Да нет не на мой — наша контора занимается автоматизацией одного предприятия уже 13 лет. по скромным оценкам там от 500 до 1000 человеко-лет вложено.
И могу тебе сказать — большим предприятиям еще важнее актуальность информации, чем мелким. в конце концов, в мелком предприятии одну и ту же сущность могут менять один-два человека, а в больших счет идет на сотни.

>> TK>1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер.
>> Насчет количества блокировок на отдельном сервере — согласен, а вот длительность блокировок будет длиннее, так как при завершении транзакции более сложной, чем изменение одной записи в одной некластеризованой таблице потребует (с большой вероятностью) согласования между серверами, распределенных транзакций, что лишь повысит нагрузку на сервер при блокировке... так что тяжело решить однозначно что тут лучше — от задачи зависит.

TK>что тебе так дался этот кластер? одну таблицу так-же можно на несколько серверов растащить... и без кластера.
я уже писал про кластеризованую таблицу. в данном случае имеется ввиду кластеризация как разделение одной сущности на несколько частей.

>> ЗЫ ко всему сразу... начал я писать этот ответ примерно в 09:00 по Москве, так что ежели чего пропустил — не обессудьте

TK>Мы тут так долго сотояние не держим =)
Ну, судя по перечитаному остальному треду — вполне...

... << RSDN@Home 1.1.2 beta 2 >>

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

Кароче — привел все мои доводы, которые я хотел IT'у сказать... но ты успел пока я обедал

... << RSDN@Home 1.1.2 beta 2 >>

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

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

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

В>>Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом

TK>С весенними ручьями он слился

Вобщем утекает COM+ (да и COM вообще) как песок через пальцы...

А кто будет играть его роль? Индиго?

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

AVK>>А какой смысл фиксировать транзакцию в памяти?
M>А это не я придумал..

А кто? Точно не я

M>Ну почитай сообщение ГВ с которого все началось. Он-то как раз пропагандирует отложенную запись в БД, то есть фактически фиксацию в памяти..

Отложеная запись это совершенно отдельный разговор. Мы же пока, надеюсь, говорим о stateless vs stateful.

... << RSDN@Home 1.1.2 beta 2 >>

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

M>Правильно. Но по сценарию ГВ, с отложенной записью в БД, и закоммиченые тоже, поэтому durability и идет лесом.

Нет, если уж у нас запись отложеная то естественно ни о какой durability и речи быть не может. Все что можно съэкономить на записи в этом плане это при последующем чтении только что отмодифицированного объекта не лезть опять в БД.

M>Если же применяется UNDO схема — все не зафиксированные изменения держатся в памяти, то в силу того, что незафиксированых изменений, при большой нагрузке, может быть довольно много, будет происходить перерасход памяти.
M>То есть сервер вносит изменения на диск, потому что в большинстве случаев так выгоднее.

А вот тут я бы не стал обобщать.

... << RSDN@Home 1.1.2 beta 2 >>

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

В>Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом

Ага, в экстазе. Причем настолько сольется что собственно от СОМ+ там почти ничего и не останется

. ИМХО работу СОМ+ объектов в индиге через нетовский интероп сложно назвать нормальным развитием.

... << RSDN@Home 1.1.2 beta 2 >>

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

S>Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

Так с лайком и у sql-сервера не все шоколадно

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.

А не передергиваешь? Нет, понятно что reference constraint нужно делать средствами БД, но городить навороченные триггеры точно не стоит. Вот у меня под боком живой пример. Обращение к одной из вьюх примерно в 200 раз медленнее прямого доступа к таблице. При этом вьюха отличается всего лишь проверками. Сервер приложений такую проверку сделает со свистом.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>Во время, отведённое мне на разработку чего?

А оптимизация... Не так страшен чёрт, как...

IT>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы. Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.
Ну не скажи... B+Дерево пишется на коленке за 2 часа первый раз, а второй (я думаю) я напишу и того быстрее.. а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.
А само исполнение запросов.. ну, могу тебе сказать, что в объектных системах SQL как таковой не нужен при запросах к бизнес данным. SQL нужен при запросе к хранилищу, а при запросе к бизнес данным все просто — у нас нет агрегирующих ыункций — раз и мы возвращаем объекты целиком — два (а иначе — это уже не ОО)

ГВ>>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?

IT>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.
Ага... теперь смотрим по Ctrl+F5 ту же страницу.... упс, а она уже совсем другая

незадача, однако...

... << RSDN@Home 1.1.2 beta 2 >>

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

S>>Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...
AVK>Так с лайком и у sql-сервера не все шоколадно

Не, вот именно с таким лайком, как раз все шоколадно..

AVK>Запятая это десятичная или просто отделение порядка?
порядок

... << RSDN@Home 1.1 beta 1 >>

TK>[skip такому тестику]

>>
>> попробуй выполнить и прочувствовать разницу.
>> у меня профайлер сказал:
>> M1 — 4,290
>> M2 — 165
>>
>> Просто в последнее время стало модным забивать и забиватся на сервер БД. Ну не эффективно это во многих случаях и приходится ручками лепить довольно много. Не надо делать из сервера БД — спасателей, которые всегда спешат на помощь (c) TK.

TK>А теперь давай положим в эту табличку пару миллионов записей, и начнем выбирать данные из случайного места. И еще не забудь добавить в свой тестик обновление кеша — данные меняются и кеш надо иногда перезагружать. А для пущей реальности, добавим еще пару табличек роли — там какие-нибудь и еще какой-нибудь ерунды в том-же стиле... Плюс сделаем вид, пользователи иногда логинятся — так что, поищем еще и по имени...
TK>И тогда, мы еще раз поиграем в спасателей. Только боюсь как-бы M2 не пролетел мимо дерева

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

... << RSDN@Home 1.1 beta 1 >>

M>А когда ты ее начать успел? У тебя же все в памяти....
Ты меня совсем не понял. Вот скажем то о чм я говорю:

public class Foo
{
    private String userName;
    private String userPass;
        
    public void Bar()
    {
        userPass = "123";
        throw new SecurityException(); // вот после этого состояние userPass возвращается в исходное
    }
}

Я не хотел ничего никуда на диск пихать. Я просто хотел сказать что это возможно и даже довольно красиво реализуется (я Так думаю

)

... << RSDN@Home 1.1 beta 1 >>

IT>Сообщения у нас и так кешируются. Только не десять тысяч последних, а те к которым было недавнее обращение.
А толку то. Я имел в виду закэшировать скажем датасет с ~10000 сообщений. Что у нас самые частые операции? Я думаю
*чтение списка оглавления сообщений
*чтение списка сообщений некоторой темы
*чтение самого сообщения

Вот первые 2 пункта представляют собой довольно простые запросы. Если сделать нейкий кэш то работа должны ускорится довольно ощутимо. Ну нафига постоянно лазить в базу если у нас чтений на порядок больше чем записей.

Tom>>поправь меня если я тут это

не прав в общем

IT>Неправ. Сообщения у нас кешируются не потому что sql сервер не успевает, а потому что расцветка синтаксиса тормозит. Вот и делай теперь выводы

Делаю. Надо её на клиента переносить. Причём и построение самого дерева тоже.

... << RSDN@Home 1.1 beta 1 >>

... << RSDN@Home 1.1.2 beta 2 >>

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

Tom>Сделал мааааленький тестик. Если хранить таблицу users просто в датасете, то получается ~ 1mb per 1.000 users. Т.е всего 20mb пер олл юзерс. Можно ещё последних ~10 тысяч сообщений хранить. Вроде как памяти хватает а сиквел это должно порядочно разгрузить.

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

... << RSDN@Home 1.1.2 beta 2 >>

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

В>А кто будет играть его роль? Индиго?

Ага.

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>>А теперь давай положим в эту табличку пару миллионов записей, и начнем выбирать данные из случайного места. И еще не забудь добавить в свой тестик обновление кеша — данные меняются и кеш надо иногда перезагружать. А для пущей реальности, добавим еще пару табличек роли — там какие-нибудь и еще какой-нибудь ерунды в том-же стиле... Плюс сделаем вид, пользователи иногда логинятся — так что, поищем еще и по имени...
TK>>И тогда, мы еще раз поиграем в спасателей. Только боюсь как-бы M2 не пролетел мимо дерева

Tom>А не надо везде, где не надо звать спасателей. У них работа другая. Я тебе хотел всего лишь показать, что не всегда правильно всё пихать на сервер БД. Умный кэш — это хорошее решение. Я ж не спорю, что база данных это зэ бэст. Я говорю, что можно сделать ещё лучше и мой тест — всего лишь тому подтверждение.

в твоем примере — умным решением было-бы закешировать результат "SELECT * FROM users where id=4" (что и было-бы сделано в ральной архитектуре), а не тянуть всю таблицу к себе. Вот и оцени трудо затраты — "выборка из базы + кеширование на пару секунд" против полноценной реализации из второго варианта.

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

Tom>Вот первые 2 пункта представляют собой довольно простые запросы.
Это ты так думаешь.

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

TK>>Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать.
H_D>Да ну? КАК ты добъешься актуальности данных в стейтлесс? будешь постоянно сдергивать с сервера "изменения за период времени"?? так это же твою сеть положит...
H_D>а сервер оповещать не сможет... он же стейтлесс — даже если он знает сколько у него клиентов — он что на каждый чих будет оповещать ВСЕХ???
H_D>а если их 100 000?

А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall?
Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз?

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

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

... << RSDN@Home 1.1.2 beta 2 >>

TK>в твоем примере — умным решением было-бы закешировать результат "SELECT * FROM users where id=4" (что и было-бы сделано в ральной архитектуре), а не тянуть всю таблицу к себе. Вот и оцени трудо затраты — "выборка из базы + кеширование на пару секунд" против полноценной реализации из второго варианта.

Да ёлы палы. Что ето со всеми. Я ещё раз повторяю. Пример с потолка. Предназначегн только для того, что бы показать, что не надо всё ложить на базу! Больше ничего я им сказать не хотел.

... << RSDN@Home 1.1 beta 1 >>

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

Tom>Да ёлы палы. Что ето со всеми. Я ещё раз повторяю. Пример с потолка. Предназначегн только для того, что бы показать, что не надо всё ложить на базу! Больше ничего я им сказать не хотел.

Тогда соило использовать не базу, а текстовый файл. Или просто константу к потолку прибить.

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

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

TK>>>Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать.
H_D>>Да ну? КАК ты добъешься актуальности данных в стейтлесс? будешь постоянно сдергивать с сервера "изменения за период времени"?? так это же твою сеть положит...
H_D>>а сервер оповещать не сможет... он же стейтлесс — даже если он знает сколько у него клиентов — он что на каждый чих будет оповещать ВСЕХ???
H_D>>а если их 100 000?

TK>А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall?
TK>Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз?
Так, я не понял... если мы говорим о стейтлесс — какой SQL Server Notification Services?? а если мы храним контекст пользователя — это не стейтлесс..
кстати, нашел еще одну задачу, где WebServices рулят перед Remoting'ом — при написании клиентов под CompactFramework

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Если транзакция распространяется на несколько методов то уже не стейтлес, ибо транзакция суть состояние.

TK>Это уже не состояние, а демагогия.

А по мне так самое натуральное состояние. Иначе непонятно что же тогда вобще состояние.

TK>С тем-же успехом можно сказать, что транзакция это процесс перехода из одного устойчивого состояния в другое устойчивое состояние.

Можно. А что это даст?

TK>А учитывая, что две разных транзакции изолированы друг от друга — можно сказать, внутрее состояние транзакции является неопределенной величиной для стороннего наблюдателя.

Ну смотря какой наблюдатель. Если наблюдатель из другой транзакции то да.

TK> Так что-же это за состояние, которое нельзя ни измерить, ни увидеть?

Его можно и измерить и увидеть службам сервера приложений и собственно участнику транзакции.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Запятая это десятичная или просто отделение порядка?
Tom>порядок

Тогда понятно

... << RSDN@Home 1.1.2 beta 2 >>

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

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

M>>Если же применяется UNDO схема — все не зафиксированные изменения держатся в памяти, то в силу того, что незафиксированых изменений, при большой нагрузке, может быть довольно много, будет происходить перерасход памяти.
M>>То есть сервер вносит изменения на диск, потому что в большинстве случаев так выгоднее.

AVK>А вот тут я бы не стал обобщать.
А я и не обобщаю.. Я очень аккуратно написал "в большинстве случаев".

На самом деле схема с undo/redo достаточно гибкая, чтобы пока память есть, диск не трогать, а как только память становится нужна для более других нужд, то незафиксированные данные можно себе позволить скинуть в лог.

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

M>>А когда ты ее начать успел? У тебя же все в памяти....
Tom>Ты меня совсем не понял. Вот скажем то о чм я говорю:
Нет это ты не понял..

Про откат все ясно, не ясно про фиксацию...

Tom>Я не хотел ничего никуда на диск пихать.
А надо. В том-то вся и проблема, что надо, и от этого не отвертеться.

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

AVK>А кто? Точно не я

ГВ, а Tom его поддерживает почему-то..

AVK>Отложеная запись это совершенно отдельный разговор. Мы же пока, надеюсь, говорим о stateless vs stateful.
Не, у нас тут как раз тот самый отдельный разговор..

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

AVK>>А вот тут я бы не стал обобщать.
M>А я и не обобщаю.. Я очень аккуратно написал "в большинстве случаев".

Знаешь как ты писал, осторожно или держа по ножу в каждой руке и отчаяно ими махая, я не видел. Но когда человек говорит в большинстве случаев он имхо обобщает.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Отложеная запись это совершенно отдельный разговор. Мы же пока, надеюсь, говорим о stateless vs stateful.
M>Не, у нас тут как раз тот самый отдельный разговор..

То есть пьянка перешла в следующую стадию и народ разбился на кучки по интересам?

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>>А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall?
TK>>Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз?
H_D>Так, я не понял... если мы говорим о стейтлесс — какой SQL Server Notification Services?? а если мы храним контекст пользователя — это не стейтлесс..

Нет никакого контекста пользователя. Клиент просто вызывает веб метод, где указывает свой endpoint и в каких уведомлениях он заинтересован. Никакого глобального состояния в памяти держать не надо — это примитивная операция которая сравни подписке на любую рассылку.

Здравствуйте, IT, Вы писали:
IT>Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.
А, ну в таком случае я полностью согласен. Я как раз защищал декларативные констрейнты, ибо они дают пищу для ума оптимизатора. А все процедурные констрейнты (типа триггеров) мне очень хочется перенести в App-сервер.

... << RSDN@Home 1.1.0 stable >>

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

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

AVK>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
Хм. горячие парни. Я как-то полагал, что страшное слово stateless относится именно к модели сервера приложений, в которой он отказывается от хранения состояния. При этом он полностью полагается на DBMS (ну, или в более широком смысле слова — на произвольный нижележащий уровень) в том, что касается состояния системы. Надо отметить, что совсем stateless системы — это не более чем игрушка для ума, набор процедурной логики. Складывалка 2+2 — один из примеров. Все интересные сиситемы помимо поведения должны поддерживать еще и состояние. Но это никак не противоречит выбору stateless модели для одного из уровней системы, пока нижние уровни несут на себе этот state.

... << RSDN@Home 1.1.0 stable >>

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

хъ

ZEN>Что скажете? Интересно было бы послушать альтернативщиков платформы MS, прежде всего из стана Java.

Слушаем тебя с нетерпением.

... << RSDN@Home 1.1.0 stable >>

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

Tom>Я тебе хотел всего лишь показать, что не всегда правильно всё пихать на сервер БД.
Да кто бы спорил.

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

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

TK>>Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью).

AVK>Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят?

Говорят о тормознутости. Говорят об использовании мощных и дорогих санов для того чтобы это хоть как-то дышало. Говорят о системах под ключ стоимостью в десятки раз больше чем аналогичные для Windows.

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

IT>>Это само собой. Просто stateful это хорошая питательная среда для выращивания крупномасштабных глюков. Так что кривые руки + stateful... просто страшно подумать что может получиться.

AVK>Кто бы спорил. Создание серверов приложений было и пока что есть одна из самых сложных задач.

Усложнять — просто, упрощать — сложно (с) Закон Мейера

Сложными её делают кривые ручки.

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

[]

AVK>Примеры того когда это невозможно я уже приводил.

Ты не приводил. Ты сказал просто, что это невозможно, тогда как у меня работает?

З.Ы. Опишу попозжа.

... << RSDN@Home 1.1.0 stable >>

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

хъ

H_D>Ну не скажи... B+Дерево пишется на коленке за 2 часа первый раз, а второй (я думаю) я напишу и того быстрее..

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

H_D> а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.

За 2 часа? Ох уж этот юношеский максимализм.

H_D>А само исполнение запросов.. ну, могу тебе сказать, что в объектных системах SQL как таковой не нужен при запросах к бизнес данным. SQL нужен при запросе к хранилищу, а при запросе к бизнес данным все просто — у нас нет агрегирующих ыункций — раз и мы возвращаем объекты целиком — два (а иначе — это уже не ОО)

Т.е. эти агрегаты сами из воздуха появляются?

хъ

IT>>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.
H_D>Ага... теперь смотрим по Ctrl+F5 ту же страницу.... упс, а она уже совсем другая

незадача, однако...

Ты что этим хотел сказать?

... << RSDN@Home 1.1.0 stable >>

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

хъ

AVK>Так с лайком и у sql-сервера не все шоколадно

А как ты его в своем коде будешь эмулировать? Только не говори, что регулярными выражениями.

... << RSDN@Home 1.1.0 stable >>

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

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

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

С чем? С кривым дизайном?

... << RSDN@Home 1.1.0 stable >>

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

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

IT>>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.

AVK>А не передергиваешь? Нет, понятно что reference constraint нужно делать средствами БД, но городить навороченные триггеры точно не стоит. Вот у меня под боком живой пример. Обращение к одной из вьюх примерно в 200 раз медленнее прямого доступа к таблице. При этом вьюха отличается всего лишь проверками. Сервер приложений такую проверку сделает со свистом.

С++ порождает код в несколько раз быстрее дотнетовского. Все летает со свистом. Однако же ты используешь дотнет, потому что он проще и на нем легче писать грамотный код. Тут фактически, тот же выбор.

... << RSDN@Home 1.1.0 stable >>

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

TK>>Это уже не состояние, а демагогия.

AVK>А по мне так самое натуральное состояние. Иначе непонятно что же тогда вобще состояние.

Вот может ты и дашь определение как автор этого термина

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

IT>>Дать ему уникальный guid при создании.

AVK>Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.

А ты можешь провести чёткую грань?

IT>>Откуда сделан такой вывод?

AVK>А вот предложения ТК и твои лучшим образом это подтвердили. И он и ты постоянно предлагаете мне править прикладной код для решения задачи управления.

Я тебе предлагаю не изобретать велосипеды.

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

AVK>Я? Я пока что ничего не решаю. Я собственно и решения то не предлагал никакого.

То что ни решения, ни одного конкретного примера — это я заметил

Всё больше намёки о существовании некоего невероятно крутого сервера приложений

IT>> переписывать бизнес-правила тебе не придётся. Только перерисовывать

AVK>Это уже детали. Впрочем в данном конкретном случае может оно и прокатит. Не зальешь дистрибутив на сервер?

Надо будет пошукать.

IT>>Ты делаешь свою систему как коробочный продукт или на заказ/для своей конторы?

AVK>Черт его знает. Пока точно не известно. Вероятность того что это будет коробка не нулевая. Даже если это будет внутренний продукт совершенно точно его будут пользовать внедрюки в различных филиалах.

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

AVK>Спасибо что разъяснил

. А бизтолк не катит, его стоимость для конечного решения будет дороже того за что можно наш продукт продать

.

Козлы они. Смотрят на Ремеди и Оракл и цены задирают. Удержать такие цены на подобные системы можно только вступив с остальными производителями в сговор.

IT>>Это тут при чём? Или у стэйтфул программистов есть секретарши, которым они надиктовывают свой код?

AVK>Нет, у них есть сервер приложений.

Сервер у всех есть.

IT>>Код то всё равно писать

AVK>Код управления состояниями?

Я тебе уже доложил. Код о котором ты говоришь вообще писать не надо, его можно рисовать.

IT>>Ничего оно не ограничивает. А совсем наоборот. Благодаря простоте реализации stateless оставляет больше времени, чтобы бегать по этим просторам.

AVK>Ну да, вроде хранения состояния в БД всегда, даже если его хранить то надо десяток секунд.

Если пользователь нажал Save и перешёл к другой операции, то хранить надо даже пол секунды. Документ, появившийся в системе не должен из неё исчезать бесследно. Хотя... учитывая твои слова о специфики российского бизнеса всё возможно

AVK>>>Хороши усилия — после каждого запроса скидывать состояние в БД

IT>>Подожди, подожди. А разве у тебя состояние объектов может не соответствовать их состоянию в БД?

AVK>В незакрытой транзакции? Может конечно, иначе ради чего огород городить?

Т.е. мы опять приходим к тому, что если кончилась батарейка, то тётя Маша, нажавшая за секунду до этого Save, сама дура. Найс. Андрей, ты понимаешь что это не серьёзно? О том, к чему может привести такая "оптимизация", дети BL-девелоперов проходят в детском саде.

AVK>А кто спорит. Просто необходимость непрерывно переписывать бизнес-логику начисления приводит к возрастанию фактора простоты написания этой бизнес-логики. Ты думаешь почему у 1С предприятия практичеси полное доминирование на рынках малых и средних предприятий? А вот в Америке почему то подобных решений не замечено.

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

AVK>>>Слова Стива Шварца помнишь?

IT>>Какие именно

AVK>Те самые, которые я процитировал в самом начале.

В начале чего

IT>>На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.

AVK>Напиши ему.

Врад ли поможет.

IT>>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок

AVK>Так идея то в том чтобы это реализовать один раз, а не каждый раз когда нужна новая бизнес-логика.

А ты ничего не пишешь когда тебе нужна новая бизнеслогика? Странно

IT>>Ты так думаешь потому что тебе это просто пока не приходилось делать

AVK>И, надеюсь, не придется. В технических авантюрах, вызванных бредом воспаленного разума технически безграмотных менеджеров участвовать не собираюсь.

Правильно. Гораздо эффективнее в десятый раз изобрести ещё один велосипед

IT>>Что-то я тут опять мало что понял. Закладвать в архитектуру расширяемость можно и нужно всегда.

AVK>Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?

Она у меня уже есть по умолчанию. Называется веб-сервисы

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

AVK>>А не передергиваешь? Нет, понятно что reference constraint нужно делать средствами БД, но городить навороченные триггеры точно не стоит. Вот у меня под боком живой пример. Обращение к одной из вьюх примерно в 200 раз медленнее прямого доступа к таблице. При этом вьюха отличается всего лишь проверками. Сервер приложений такую проверку сделает со свистом.

AS>С++ порождает код в несколько раз быстрее дотнетовского. Все летает со свистом. Однако же ты используешь дотнет, потому что он проще и на нем легче писать грамотный код. Тут фактически, тот же выбор.

Во-первых насчет нескольких раз ты перебрал, а во-вторых по твоему сложные проверки легче писать не на шарпе, а на tsql, так что ли?

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы.

ГВ>А... это, в разработку системы вполне может быть включена разработка соответствующих stateful-сервисов.

Это ты АВК расскажи. У него BL-девелоперы такой фигнёй не страдают, у них есть The App-Server, который уже всё умеет

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

AVK>А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.

Я о прерогативах ничего не говорил.

IT>>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.

AVK>Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.

Ты опять кидаешься ни чем не обоснованными обвинениями. Я разве говорил что кешь должен быть только на клиенте. Я говорил, что он тем эффективнее, чем ближе к потребителю. Чувствуешь разницу?

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

H_D>> а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.

AS>За 2 часа? Ох уж этот юношеский максимализм.

Ну почему же? Вполне возможно. Только он потом ещё двое суток это отлаживать будет

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

AVK>>Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.

IT>А ты можешь провести чёткую грань?

Между бизнес-логикой и кодом управления процессом? Могу.

AVK>>А вот предложения ТК и твои лучшим образом это подтвердили. И он и ты постоянно предлагаете мне править прикладной код для решения задачи управления.

IT>Я тебе предлагаю не изобретать велосипеды.

А где я такое предлагал? Вот ваша эмуляция состояний при помощи отдельной БД это точно велосипед. И ваши гуиды вместо нормальных транзакций тоже велосипед.

AVK>>Я? Я пока что ничего не решаю. Я собственно и решения то не предлагал никакого.

IT>То что ни решения, ни одного конкретного примера — это я заметил

Всё больше намёки о существовании некоего невероятно крутого сервера приложений

И это неверно. Намеки это у ГВ, а я ни про что не намекал. Я сразу же специально написал — никакой конкретики, одна философия.

AVK>>Это уже детали. Впрочем в данном конкретном случае может оно и прокатит. Не зальешь дистрибутив на сервер?

IT>Надо будет пошукать.

Да, вот тока что товарища с МС проводили. Вобщем не катит похоже бизтолк, не то это. Надо смотреть. Как будет время залезу в msdn, поковыряю его локально.

AVK>>Черт его знает. Пока точно не известно. Вероятность того что это будет коробка не нулевая. Даже если это будет внутренний продукт совершенно точно его будут пользовать внедрюки в различных филиалах.

IT>Так может тогда стоит делать всё по нормальному?

По нормальному это стейтлес?

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

Стоимость предыдущего решения в этом секторе примерно 700 баксов на 5 пользователей.

IT>Я тебе уже доложил. Код о котором ты говоришь вообще писать не надо, его можно рисовать.

По барабану. Я предпочитаю все что можно сделать автоматически, без участия пользователя делать автоматически.

AVK>>Ну да, вроде хранения состояния в БД всегда, даже если его хранить то надо десяток секунд.

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

Подожди, ты чего то не понял. В пределах транзакции нажатие Save не в корневом контексте не должно приводить к появлению чего то вне транзакции. Это требование ТЗ, обсуждать это бессмысленно. Если оно появилось в системе значит транзакция завершена и говорить вобще не о чем.

AVK>>В незакрытой транзакции? Может конечно, иначе ради чего огород городить?

IT>Т.е. мы опять приходим к тому, что если кончилась батарейка, то тётя Маша, нажавшая за секунду до этого Save, сама дура. Найс. Андрей, ты понимаешь что это не серьёзно?

Что несерьезно? Что при сбое транзакции она должна быть полностью откачена? Я это даже обсуждать не хочу, транзакция без атомарности это не транзакция а какая то фигня.

IT>О том, к чему может привести такая "оптимизация", дети BL-девелоперов проходят в детском саде.

Это уже не оптимизация, это транзакционность и эти самые дети должны понимать что такое транзакция.

AVK>>А кто спорит. Просто необходимость непрерывно переписывать бизнес-логику начисления приводит к возрастанию фактора простоты написания этой бизнес-логики. Ты думаешь почему у 1С предприятия практичеси полное доминирование на рынках малых и средних предприятий? А вот в Америке почему то подобных решений не замечено.

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

Вот о том и речь что не понимаешь.

Фишка не в правке чего то вами без перекомпиляции, фишка в возможности глубокой правки системы самим заказчиком вплоть до добавления своих документов, OLTP регистров и прочая. МС вот грозится выпустить на российский рынок MBF и выгнать с него 1С и всех остальных, но это будет относительно нескоро. А пока же никаких подходящих западных решений для малого и среднего бизнеса нет.

AVK>>Те самые, которые я процитировал в самом начале.

IT>В начале чего

Разговора.

IT>>>На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.

AVK>>Напиши ему.

IT>Врад ли поможет.

Ну ты напиши, а потом обсудим, помогло или нет

IT>>>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок

AVK>>Так идея то в том чтобы это реализовать один раз, а не каждый раз когда нужна новая бизнес-логика.

IT>А ты ничего не пишешь когда тебе нужна новая бизнеслогика?

В ядре то? Нет конечно. Я (ну не я конечно) пишу исключительно бизнес-логику. Уж точно не пишу каждый раз механику отката, как здесь предлагается.

AVK>>И, надеюсь, не придется. В технических авантюрах, вызванных бредом воспаленного разума технически безграмотных менеджеров участвовать не собираюсь.

IT>Правильно. Гораздо эффективнее в десятый раз изобрести ещё один велосипед

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

AVK>>Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?

IT>Она у меня уже есть по умолчанию. Называется веб-сервисы

Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Сложными её делают кривые ручки.

Я что то пока не видел просто написанных серверов приложений. Так что, приходится полагать что у всех программистов руки кривые?

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят?

IT>Говорят о тормознутости.

Ты с ними сам работал? А то вон почитаешь про mssql у ораклей так тоже такой тормоз что мама дорогая.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.

IT>Я о прерогативах ничего не говорил.

То есть речь уже не о stateless/stateful? Ну тогда я пас.

AVK>>Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.

IT>Ты опять кидаешься ни чем не обоснованными обвинениями. Я разве говорил что кешь должен быть только на клиенте. Я говорил, что он тем эффективнее, чем ближе к потребителю. Чувствуешь разницу?

Ну IT, от тебя я такого не ожидал, обычно этим несколько другой человек страдает.

Я об этом.

если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту,

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

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Вот может ты и дашь определение как автор этого термина

Да не ребята, я в отличие от вас свою трактовку вводить не собираюсь.

stateless object объект, не меняющий своего состояния в процессе исполнения
stateful object объект, кумулятивно изменяющий параметры своего состояния в процессе исполнения по вызовам клиентов

(С)Лингво

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>>А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.

IT>>Я о прерогативах ничего не говорил.

AVK>То есть речь уже не о stateless/stateful? Ну тогда я пас.

Не надо выворачивать. Я ничего не говорил о наличии/отсутствии объектных запросов в стайтлес модели.

AVK>>>Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.

IT>>Ты опять кидаешься ни чем не обоснованными обвинениями. Я разве говорил что кешь должен быть только на клиенте. Я говорил, что он тем эффективнее, чем ближе к потребителю. Чувствуешь разницу?

AVK>Ну IT, от тебя я такого не ожидал, обычно этим несколько другой человек страдает.

AVK>Я об этом.
AVK>

AVK> если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту,

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

Если я вынесу справочники на клиента, то попадание всегда будет 100%. Что здесь не так? К тому же чем ближе к клиенту, тем уже более обработаны данные. Или тебе еще раз привести пример с браузером?

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

IT>>Говорят о тормознутости.

AVK>Ты с ними сам работал? А то вон почитаешь про mssql у ораклей так тоже такой тормоз что мама дорогая.

А ты? Я наблюдал как с этим г. (извиняюсь за выражение) парился народ который нам устанавливал это барахло. Зная сколько стоит под это техника и сколько сам софт. Всё это шевелица только благодаря супермощной технике, за которую платит между прочим заказчик.

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

AVK>Да не ребята, я в отличие от вас свою трактовку вводить не собираюсь.

AVK>stateless object объект, не меняющий своего состояния в процессе исполнения
AVK>stateful object объект, кумулятивно изменяющий параметры своего состояния в процессе исполнения по вызовам клиентов

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

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

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

AVK>Ну тогда и я неверно твои слова истолковал. ИМХО ты плохо выразился.

Возможно. Но скорее всего ты додумал то, что хотел

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

H_D>Кароче — привел все мои доводы, которые я хотел IT'у сказать... но ты успел пока я обедал

Спрятался за широкой спиной АВК? Понятно

Здравствуйте, 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 не было

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

H_D>когда я говорю "Написать за два часа" — это значит написать и отладить...

Молодец

А мы медленно, медленно спустимся с горы и ...

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

AVK>>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
S>Хм. горячие парни. Я как-то полагал, что страшное слово stateless относится именно к модели сервера приложений, в которой он отказывается от хранения состояния. При этом он полностью полагается на DBMS (ну, или в более широком смысле слова — на произвольный нижележащий уровень) в том, что касается состояния системы. Надо отметить, что совсем stateless системы — это не более чем игрушка для ума, набор процедурной логики. Складывалка 2+2 — один из примеров. Все интересные сиситемы помимо поведения должны поддерживать еще и состояние. Но это никак не противоречит выбору stateless модели для одного из уровней системы, пока нижние уровни несут на себе этот state.

И уж тем более не противоречит, если тебе нужно продать некий конкретный SQL-сервер вместе с некой конкретной коммуникационной средой.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Так с лайком и у sql-сервера не все шоколадно

AS>А как ты его в своем коде будешь эмулировать? Только не говори, что регулярными выражениями.

Хм... а передать SQL-серверу задачи поиска уже нельзя?

... << RSDN@Home 1.1.2 beta 2 >>

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

TK>>>Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?
Tom>>А что это трудно сделать? Вроде как нет

M>В памяти ACID вообще нелья сделать... електричество кончилось и опаньки, вся durability идет лесом.

Да, это не совсем полновесный durability, конечно. Откладывать запись можно, как минимум, обеспечивая надёжность питания системы. Но если эта "дырка" прикрыта, то никаких принципиальных препятствий для обеспечения durability, вобщем-то, нет... за исключением возможной ненадёжности и нестабильности модулей памяти App-сервера.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Ну тогда и я неверно твои слова истолковал. ИМХО ты плохо выразился.

IT>Возможно. Но скорее всего ты додумал то, что хотел

То что помимо меня точно так же додумал и Синклер наводит на размышления, не находишь?

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Но при этом проверку обязательно нужно повторить на сервере.

IT>Обязательно. И ещё потом кое-что в БД.

О, уже кое что, а не все. Прогресс

AVK>>Вот говорю же я что ты от российских реалий слишком отдалился. Проблема обновления софта по всему миру в тысячах офисов перед большинством российских компаний пока не стоит.

IT>Это плохая отмазка. Типа в нашей деревне это не надо.

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

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

IT>А кто у вас определяет востребованность?

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

IT>>>Хана твоему ООП. Сегодня рулят схемы и контракты

AVK>>Пока что только на бумаге.

IT>Скоро будут и в Индиге.

В индиге много чего будет. Вон веб-сервисы с самого первого фреймворка есть, только рулежа что то не особенно заметно, по крайней мере в России. Один DigiDes чего то там дергался, но выхлоп совсем бледный какой то.

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

AVK>>Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.

IT>Я сказал что-то другое?

Ну так перечитай себя. У тебя под стейтлес явно подразумевается что то куда более хитрое. Ну типа есть кошерный стейтлес и некошерный стейтлес (не по Боксу)

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

Да, вот как раз меня и надо обвинять в зацикливании на какой то модели

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

. Так кто из нас зацикливается?

IT>>>Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества

AVK>>Опять ты в крайности ударяешься

IT>Это ты насчёт преимуществ?

Это насчет никаких недостатков. Недостатки есть у обоих моделей и глупо их игнорировать.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>>Я о прерогативах ничего не говорил.

AVK>>То есть речь уже не о stateless/stateful? Ну тогда я пас.

IT>Не надо выворачивать. Я ничего не говорил о наличии/отсутствии объектных запросов в стайтлес модели.

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

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

IT>Если я вынесу справочники на клиента, то попадание всегда будет 100%.

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

IT>Что здесь не так? К тому же чем ближе к клиенту, тем уже более обработаны данные. Или тебе еще раз привести пример с браузером?

А чем дальше от клиента тем больше и эффективнее может заполняться кеш. Вобщем не надо обобщать

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Между бизнес-логикой и кодом управления процессом? Могу.

IT>И у тебя всегда управление процессом покрывает все мыслемые нужды бизнес-логики?

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

AVK>>А где я такое предлагал? Вот ваша эмуляция состояний при помощи отдельной БД это точно велосипед. И ваши гуиды вместо нормальных транзакций тоже велосипед.

IT>Возможно, но мы не делаем таинственное выражение лица, когда говорим о наших велосипедах.

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

IT>Тогда нам тяжело будет беседовать. Мне всегда было интересно знать физику процесса, а не рассказы о том, что она есть.

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

IT>Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?

Нет конечно, с чего ты взял?

IT>Сдаётся мне ты что-то путаешь в терминологии или слишком путано объясняешь. Пример приводить ты как всегда не будешь.

Не буду

AVK>>Ну ты напиши, а потом обсудим, помогло или нет

IT>Дашь референс?

А он что, публично недоступен? stevesw@microsoft.com

AVK>>Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем

IT>Я ими связывал .NET и Java. Особых проблем у меня на стороне .NET не было

А на стороне джавы?

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>А ты? Я наблюдал как с этим г. (извиняюсь за выражение) парился народ который нам устанавливал это барахло.

А я наблюдал как с другим г., СОМ+ тоже народ парился до изнеможения. И Что это доказывает?

IT> Зная сколько стоит под это техника и сколько сам софт.

Ну вот JBoss к примеру бесплатен и исходники доступны. А Orion идет в комплекте с ораклем.

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>stateless object объект, не меняющий своего состояния в процессе исполнения
AVK>>stateful object объект, кумулятивно изменяющий параметры своего состояния в процессе исполнения по вызовам клиентов

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

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

... << RSDN@Home 1.1.2 beta 2 >>

Здравствуйте, 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>Не говоря уже о том, что когда на сервере-таки питание кончится, то уборщице, с ее шваброй, конечно, по голове дадут, но тебе тоже будет больно и обидно, а отмазки типа "ну надо было питание обеспечивать" как правило не канают.

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

... << RSDN@Home 1.1.2 beta 2 >>

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

S>Все зависит от того, насколько часто апдейтится справочник.

Конечно.

S>План счетов, например, делает это крайне редко, и cache miss будет происходить раз полгода.

А другой справочник обновляется частенько и постоянное пересбрасывание кеша на клиенте может серьезно снизить эффективность кеша у клиента. Что собственно и требовалось доказать.

S>Тем не менее client-side joins — это вполне играющая технология.

Да я не спорю. Я против обобщения что клиентский кеш всегда лучше.

... << RSDN@Home 1.1.2 beta 2 >>

Здравствуйте, AndrewVK, Вы писали:
AVK>Да я не спорю. Я против обобщения что клиентский кеш всегда лучше.
Не, поинт IT был в том, что кэш на стороне сервера помогает слабо

В случае частых апдейтов кэш и на серверной стороне не спасет. Хотя... Если это кэш применения XPATH к XML, то и на серверной стороне он подымет производительность в разы...

... << RSDN@Home 1.1.0 stable >>

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

ГВ>>Да, это не совсем полновесный durability, конечно. Откладывать запись можно, как минимум, обеспечивая надёжность питания системы. Но если эта "дырка" прикрыта, то никаких принципиальных препятствий для обеспечения durability, вобщем-то, нет... за исключением возможной ненадёжности и нестабильности модулей памяти App-сервера.
M>Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.

Нет, она есть с той или иной вероятностью. Конкретные вероятности реальной durability конкретного SQL-сервера нужно считать исходя, как минимум, из MBTF винтов.

Оценки из серии "либо есть, либо ее нет" оставим для максималистов.

Просто, если гарантия "доезжания" транзакции до долговременого хранилища полностью ложится на прикладника — то да, опасность получить в целом ненадёжную систему здесь в принципе намного выше, чем когда такая операция обрабатывалается один раз написанным и отлаженным "куском кода", размещённым в App-ядре.

M>И дело даже не только в надежности питания. Может существовать еще 33 причины, по которым твоя зафиксированная в памяти транзакция до диска просто не доедет, начиная от небольших ошибок в App-коде, которые вылезут на такой вот транзакции спустя полгода после ввода системы в эксплуатацию у заказчика, и заканчивая пролетом через сервер космических частиц.

Это справедливо для любой программы на любом компьютере. Особенно — про космические частицы.

Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.

M>Не говоря уже о том, что когда на сервере-таки питание кончится, то уборщице, с ее шваброй, конечно, по голове дадут, но тебе тоже будет больно и обидно, а отмазки типа "ну надо было питание обеспечивать" как правило не канают.

Ну, во-первых, уборщица может из ведра случайно весь сервер залить и ещё на него кофе опрокинуть можно... и ещё сисадмин с ума сойти может и порубать системный блок в металлическую стружку. Так что, как ни крути, а элементарную физическую защиту машины обеспечивать всё равно нужно, как и UPS ставить.

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

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

Да, кстати, Yukon тоже чем-то аналогичным собирается баловаться — In Memory Transactions, кажется. Но это я не в "оправдание" вспоминаю, а к тому, что нет ничего абсолютного, всегда есть те или иные допуски. "В любой мышеловке есть дырочки". (c)

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>Но точно так же могут вылезти ошибки в firmware винта, что бывало уже не раз. Нет никакой абсолютной durability, есть только верояность приключения неприятностей, большая или меньшая.
Да, но при использовании БД, она гораздо более меньшая, по причине того, что там и алгоритмы, и код вылизывали годами,
а данные дублируются.
Чтобы добиться такой надежности в рукопашную, надо много усилий положить, при этом выигрыш копеечный.

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

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

Эк, блин, почти отдуплились.

Какого мы с тобой однако мнения об уборщицах.

... << RSDN@Home 1.1.2 beta 2 >>

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

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

Да никто и не спорит. Но вот говорить "Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.
" не стоит.

... << RSDN@Home 1.1.2 beta 2 >>

IT>Ага, на пару фарад

И не надо прикалыватся. Это абсолютно точное требование какого то там стандарта к современным винтам. Если уж очень интересно могу поискать попытаться.

... << RSDN@Home 1.1 beta 1 >>

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

ГВ>

Нет, она есть с той или иной вероятностью.
Ну тут я утрировал конечно..

ГВ>Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.
Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями. А в App надо написать в достаточно короткие сроки, код сильно зависимый от предметной области.
Поэтому тут с durability лучше не играться, это лишняя головная боль ради копеечного выиграша.

ГВ>При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций.
Да вот такая ли уж она допустимая? И кто будет разруливать, в каком случае допустимая, а в каком нет?
Наверняка этого сказать нельзя.

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

AVK>Да никто и не спорит. Но вот говорить "Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.
AVK>" не стоит.
Да ладно, а то ты для пущего эффекта никогда не утрируешь...

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

ГВ>>Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.
M>Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями. А в App надо написать в достаточно короткие сроки, код сильно зависимый от предметной области.

Ну, вот это — непонятно: "в достаточно короткие сроки, код сильно зависимый от предметной области" Если ты думаешь, что такая дура, как App-сервер пишется на коленках студентами-двоечниками, то... кхм. Тут только теорий и анализов больше чем на полгода возни. Было...

M>Поэтому тут с durability лучше не играться, это лишняя головная боль ради копеечного выиграша.

Спасибо, конечно, за совет,

но, ИМХО, тебе бы не стоило обобщать, или уж тогда конкретизировать: "я не буду играться с...".

ГВ>>При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций.
M>Да вот такая ли уж она допустимая? И кто будет разруливать, в каком случае допустимая, а в каком нет?
M>Наверняка этого сказать нельзя.

Нахрапом — нет, нельзя. Если подумать что да как — то можно.

... << RSDN@Home 1.1.2 beta 2 >>

M>А в App надо написать в достаточно короткие сроки, код сильно зависимый от предметной области.
Ну... на самом деле — код App Server'а вообще должен мало перекликаться с предметной облаастью... вот BL — таки да

ГВ>>При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций.
M>Да вот такая ли уж она допустимая? И кто будет разруливать, в каком случае допустимая, а в каком нет?
А можно атрибут разрешить повесить.. типа "вот эти объекты могут зависать с отложением записи до 0.5 уе"... а в конфигах сервера пишется: "В силу того, что у нас UPS обеспечивает питание всего здания в течение 20 часов — уе = 10 часов".

M>Наверняка этого сказать нельзя.
Всяко

... << RSDN@Home 1.1.2 beta 2 >>

ГВ>Да, кстати, Yukon тоже чем-то аналогичным собирается баловаться — In Memory Transactions, кажется.

Я Indigo имел ввиду.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>Да, кстати, Yukon тоже чем-то аналогичным собирается баловаться — In Memory Transactions, кажется.
ГВ>Я Indigo имел ввиду.
Во-во, а то я уж испугался...

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

ГВ>Спасибо, конечно, за совет,

но, ИМХО, тебе бы не стоило обобщать, или уж тогда конкретизировать: "я не буду играться с...".
"... и другим не советую"

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

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

AVK>Здравствуйте, Alexey Shirshov, Вы писали:

хъ

AVK>Во-первых насчет нескольких раз ты перебрал, а во-вторых по твоему сложные проверки легче писать не на шарпе, а на tsql, так что ли?

Конечно, нет. Я лишь говорю, что все проверки ограничений целостности, уникальности и другие обязаны присутствовать в sql-сервере, даже если они дублируются на коде бизнес-логики и на клиенте.

... << RSDN@Home 1.1.0 stable >>

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

ГВ>>Спасибо, конечно, за совет,

но, ИМХО, тебе бы не стоило обобщать, или уж тогда конкретизировать: "я не буду играться с...".
M>"... и другим не советую"

Ну... э... спасибо за совет.

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

Вот любишь же ты это "в принципе нельзя". Нет никакой ложки, всё — обман. (c) The Matrix

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

Да, безрадостная картина, однако.

M>В итоге и получаем, что преимуществ почти нет, написано куча кода, а надежность низкая.

А "низкая", это какая?

... << RSDN@Home 1.1.2 beta 2 >>

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

хъ

ГВ>Хм... а передать SQL-серверу задачи поиска уже нельзя?

Изначально речь вообще шла о std::map!

... << RSDN@Home 1.1.0 stable >>

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

Ок, давайте про durability и fault tolerance поподробнее поговорим.
Я это все понимаю так: у нас есть некое изменение состояния, и есть некоторые точки во времени, в которых нам чего-то говорят. Типа того, что "мы обеспечиваем сохранность этого состояния на время T с вероятностью (1-P(T)), где P(T) — что-то типа (1-exp(-T/t0)), а t0 — период полураспада соответствующего носителя.
Для обычного простого коммита этот t0 суть то самое MTBF винта, на который скидывается transaction log. Этот MTBF обеспечивается винтом вместе с кэшем, инженерными дорожками и прочими сложными материями — поскольку мы не контролируем детали этого сложного механизма, нам достаточно представлять его как черный ящик с известным MTBF. Включение/отключение аппаратного кэширования всего лишь влияет на этот MTBF, точно так же, как стабилизатор питания или RAID.
Тем не менее, MTBF этого замечательного устройства у нас ограничен сверху MTBF того, в чем он стоит. Если уборщица проливает ведро на сервер в среднем раз в месяц, то никакой суперстабильный винт не спасет.
Для защиты от таких ситуаций у нас есть более мощные средства, чем commit. Например, backup. Успешное выполнение backup означает, что мы гарантируем возврат к забэкапленному состоянию с вероятностью (1-P(T)*P2(T)), где P2 определяется MTBF хранилища backup. Произведение возникает потому, что нам надо убить оба устройства одновременно для потери и данных и бэкапа.
Таким образом, мы получаем сколь угодно близкую к 1 вероятность сохранения состояния через произвольно заданное время T. Вот это вроде как и есть durability.
Для оценки "качества durability", реализованной нестандартным способом, надо понять, какие failures ей угрожают, и какой между ними mean time. И если у нас не дай бог окажется, что MTBF значительно меньше, чем MTBF системы OS+FS Driver+HDD, то нужно отдавать себе отчет в последствиях. Еще хуже, если MTBF начинает зависеть от прикладного разработчика — прелесть RDBMS в том, что результаты коммита непреднамеренно убить невозможно. И как бы криво ни был написан прикладной код (TSQL), MTBF остается одним и тем же.

... << RSDN@Home 1.1.0 stable >>

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

ГВ>Ну... э... спасибо за совет.

Да пожалуйста, заходите ишшо.

ГВ>Вот любишь же ты это "в принципе нельзя". Нет никакой ложки, всё — обман. (c) The Matrix
Каюсь, грешен. ж) — Это внутренний констрэйнт, низя, значит низя, потому, что если чуть-чуть можно, то границы этого чуть-чуть определить очень сложно, а разгребать потом накладно. Проще сразу, низя и все..

M>>В итоге и получаем, что преимуществ почти нет, написано куча кода, а надежность низкая.
ГВ>А "низкая", это какая?
Ну просто таки "никакая"

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

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

ГВ>>Хм... а передать SQL-серверу задачи поиска уже нельзя?
AS>Изначально речь вообще шла о std::map!

Я и сейчас от std::map отказываюсь — но не для абсолютно же всех случаев поиска.

По-моему, там пример был a'la накладная и товарные позиции в ней.

... << RSDN@Home 1.1.2 beta 2 >>

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

Tom>И не надо прикалыватся. Это абсолютно точное требование какого то там стандарта к современным винтам. Если уж очень интересно могу поискать попытаться.

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

... << RSDN@Home 1.1.2 beta 2 >>

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

S>Включение/отключение аппаратного кэширования всего лишь влияет на этот MTBF,

MTBF — среднее время наработки на отказ. Обычно 20-50 тыс. часов. Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за глюков фирмваре, электроники, космических лучей. MTBF у электроники по сравнению с винтом огромен и составляет десятки лет, следовательно на MTBF системы в целом практически не влияет.

S>Тем не менее, MTBF этого замечательного устройства у нас ограничен сверху MTBF того, в чем он стоит. Если уборщица проливает ведро на сервер в среднем раз в месяц, то никакой суперстабильный винт не спасет.

По моему у тебя неверное понимание термина MTBF.

... << RSDN@Home 1.1.2 beta 2 >>

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

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

S>>Включение/отключение аппаратного кэширования всего лишь влияет на этот MTBF,

AVK>MTBF — среднее время наработки на отказ. Обычно 20-50 тыс. часов. Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за глюков фирмваре, электроники, космических лучей. MTBF у электроники по сравнению с винтом огромен и составляет десятки лет, следовательно на MTBF системы в целом практически не влияет.

AVK>По моему у тебя неверное понимание термина MTBF.
А по-моему у тебя. Не имеет смысла говорить о MTBF какого-то отдельного компонента. Вот ты говоришь "Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за ...". Зашибись, как это у нас может измениться вероятность сбоя, а мат. ожидание промежутка между сбоями не изменится? Получается, ты просто меришь mean time между одними сбоями, а учитываешь вероятность других. Вероятность получить сбой на промежутке длиной T однозначно связана с мат. ожиданием длины промежутка.
В итоге, я говорю о том, что мне по барабану, сколько часов подряд может крутиться двигатель винта. Я говорю о том, что с выключенным кэшированием сбой винта (т.е. невозможность прочитать записанные данные) возникает раз в NNNN часов, а со включенным — раз в NNNN/X часов. И именно этот суммарный MTBF и играет роль в оценке надежности моего приложения.

... << RSDN@Home 1.1.0 stable >>

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

S>А по-моему у тебя. Не имеет смысла говорить о MTBF какого-то отдельного компонента. Вот ты говоришь "Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за ...". Зашибись, как это у нас может измениться вероятность сбоя, а мат. ожидание промежутка между сбоями не изменится?

http://www.webopedia.com/TERM/M/MTBF.html

Short for mean time between failures, the average time a device will function before failing. MTBF ratings are measured in hours and indicate the sturdiness of hard disk drives and printers.
Typical disk drives for personal computers have MTBF ratings of about 500,000 hours. This means that of all the drives tested, one failure occurred every 500,000 hours of testing. Disk drives are typically tested only a few hours, and it would be unlikely for a failure to occur during this short testing period. Because of this, MTBF ratings are also predicted based on product experience or by analyzing known factors such as raw data supplied by the manufacturer.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>Вот любишь же ты это "в принципе нельзя". Нет никакой ложки, всё — обман. (c) The Matrix
M>Каюсь, грешен. ж) — Это внутренний констрэйнт, низя, значит низя, потому, что если чуть-чуть можно, то границы этого чуть-чуть определить очень сложно, а разгребать потом накладно. Проще сразу, низя и все..

Вот тут-то мы с тобой и не совпадаем.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Тогда нам тяжело будет беседовать. Мне всегда было интересно знать физику процесса, а не рассказы о том, что она есть.

AVK>Ну я вроде как и не тебе отвечал, а немного другому IT. Если хочешь услышать что то конкретное от меня — задай вопрос отдельно.

Думаешь получится?

IT>>Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?

AVK>Нет конечно, с чего ты взял?

Т.е. это всё делается одним клиентом на одной машине, так?

IT>>Сдаётся мне ты что-то путаешь в терминологии или слишком путано объясняешь. Пример приводить ты как всегда не будешь.

AVK>Не буду

Ну вот, а говоришь задавай вопросы

IT>>Дашь референс?

AVK>А он что, публично недоступен? stevesw@microsoft.com

Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

AVK>>>Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем

IT>>Я ими связывал .NET и Java. Особых проблем у меня на стороне .NET не было

AVK>А на стороне джавы?

А это были не мои проблемы.

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

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

S>>А по-моему у тебя. Не имеет смысла говорить о MTBF какого-то отдельного компонента. Вот ты говоришь "Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за ...". Зашибись, как это у нас может измениться вероятность сбоя, а мат. ожидание промежутка между сбоями не изменится?

AVK>http://www.webopedia.com/TERM/M/MTBF.html

AVK>

AVK>Short for mean time between failures, the average time a device will function before failing. MTBF ratings are measured in hours and indicate the sturdiness of hard disk drives and printers.
AVK>Typical disk drives for personal computers have MTBF ratings of about 500,000 hours. This means that of all the drives tested, one failure occurred every 500,000 hours of testing. Disk drives are typically tested only a few hours, and it would be unlikely for a failure to occur during this short testing period. Because of this, MTBF ratings are also predicted based on product experience or by analyzing known factors such as raw data supplied by the manufacturer.

Не вижу в процитированном никаких противоречий с моим мнением.

... << RSDN@Home 1.1.0 stable >>

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

AVK>>Ну я вроде как и не тебе отвечал, а немного другому IT. Если хочешь услышать что то конкретное от меня — задай вопрос отдельно.

IT>Думаешь получится?

Это уж как настроение у меня будет

IT>>>Как я понял твои транзакции начинаются и заканчиваются в разных местах разными участниками. Разве не так?

AVK>>Нет конечно, с чего ты взял?

IT>Т.е. это всё делается одним клиентом на одной машине, так?

1 транзакция? Одним клиентом конечно. Попытка влезть из другой транзакции немедленно вызывает исключение. Насчет одной машины не понял.

IT>>>Дашь референс?

AVK>>А он что, публично недоступен? stevesw@microsoft.com

IT>Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

Так, тогда объясни мне что такое референс.

AVK>>А на стороне джавы?

IT>А это были не мои проблемы.

Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

... << RSDN@Home 1.1.2 beta 2 >>

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

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

IT>>А кто у вас определяет востребованность?

AVK>Заказчик, разумеется. Конкретно для меня куча народа, ответственная за стратегию дальнейшего развития фирмы в целом и конкретного проекта в частности.

А... ну раз заканчики, то я бы на твоём месте не стал так громко за них отвечать. Сегодня они этого не хотят, завтра захотят. Бизнес штука непредсказуемая.

IT>>Скоро будут и в Индиге.

AVK>В индиге много чего будет. Вон веб-сервисы с самого первого фреймворка есть, только рулежа что то не особенно заметно, по крайней мере в России. Один DigiDes чего то там дергался, но выхлоп совсем бледный какой то.

Ну почему же. Хорошая штука для связывания разношёрстных систем. Да и янус вон как-то дышит

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

AVK>Ну так перечитай себя. У тебя под стейтлес явно подразумевается что то куда более хитрое. Ну типа есть кошерный стейтлес и некошерный стейтлес (не по Боксу)

Ну так откати на пару сообщений вверх и перечитай сам, а не выдёргивай из контекста. Ты начал с того, что объектов без состояния не бывает, так вот я тебе и другим объясняю, что название stateless эта модель дала благодаря не тем объектам о которых ты говоришь.

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

AVK>Да, вот как раз меня и надо обвинять в зацикливании на какой то модели

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

. Так кто из нас зацикливается?

Конечно же stateless лучше. И тебе тут уже неоднакратно это продемонстрировали. Но ты всё продолжаешь бубнить "не надо говорить, что stateless лучше".

IT>>Это ты насчёт преимуществ?

AVK>Это насчет никаких недостатков. Недостатки есть у обоих моделей и глупо их игнорировать.

Естественно. Редко приходится выбирать между хорошим и отличным. Чаще приходится между плохим и очень плохим. Но в данном случае нам повезло, у нас есть выбор между плохим (stateful) и приемлемым (stateless)

А вообще, давай завязывать этот спор. Кому надо тот всё понял, кому не надо, тому бесполезно что-то объяснять.

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

IT>>Возможно. Но скорее всего ты додумал то, что хотел

AVK>То что помимо меня точно так же додумал и Синклер наводит на размышления, не находишь?

Видимо он от тебя заразился

AVK>Да нет, IT прав, чтобы обеспечить нормальное питание винта несколько миллисекунд нужны конденсаторы размером с этот винт. На самом деле все проще — конденсаторы обеспечивают только питание электроники головки и буферной памяти. Вся остальная электроника вырубается, а вращение пластин обеспечивается за счет инерции.

Дык а кто говорил, что из кондёров питаются движки? Ессно только головка.

PS: Tnx что попрвил.

... << RSDN@Home 1.1 beta 1 >>

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

IT>Конечно же stateless лучше. И тебе тут уже неоднакратно это продемонстрировали. Но ты всё продолжаешь бубнить "не надо говорить, что stateless лучше".
Справедливости ради, надо заметить, что, по крайней мере изначально, он бухтел "не надо говорить, что stateless всегда лучше"

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

IT>>>А кто у вас определяет востребованность?

AVK>>Заказчик, разумеется. Конкретно для меня куча народа, ответственная за стратегию дальнейшего развития фирмы в целом и конкретного проекта в частности.

IT>А... ну раз заканчики, то я бы на твоём месте не стал так громко за них отвечать. Сегодня они этого не хотят, завтра захотят. Бизнес штука непредсказуемая.

Вот когда захотят тогда и будем делать, а пока что ...

AVK>>В индиге много чего будет. Вон веб-сервисы с самого первого фреймворка есть, только рулежа что то не особенно заметно, по крайней мере в России. Один DigiDes чего то там дергался, но выхлоп совсем бледный какой то.

IT>Ну почему же. Хорошая штука для связывания разношёрстных систем.

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

IT>Да и янус вон как-то дышит

Ты знаешь, он бы дышал ничуть не хуже, если бы там был СОМ+ или ремоутинг. Тем более что янус это чистейший стейтлес, и сделан таким преднамеренно. Там даже в БД никакого состояния не хранится, состояние отсутствует как класс.

AVK>>Да, вот как раз меня и надо обвинять в зацикливании на какой то модели

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

. Так кто из нас зацикливается?

IT>Конечно же stateless лучше.

IT>И тебе тут уже неоднакратно это продемонстрировали. Но ты всё продолжаешь бубнить "не надо говорить, что stateless лучше".

Правильно, не надо. There is no silver bullet. Все зависит от конкретной задачи.

AVK>>Это насчет никаких недостатков. Недостатки есть у обоих моделей и глупо их игнорировать.

IT>Естественно. Редко приходится выбирать между хорошим и отличным. Чаще приходится между плохим и очень плохим. Но в данном случае нам повезло, у нас есть выбор между плохим (stateful) и приемлемым (stateless)

Не обобщай.

IT>А вообще, давай завязывать этот спор. Кому надо тот всё понял, кому не надо, тому бесполезно что-то объяснять.

ОК.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Т.е. это всё делается одним клиентом на одной машине, так?

AVK>1 транзакция? Одним клиентом конечно. Попытка влезть из другой транзакции немедленно вызывает исключение. Насчет одной машины не понял.

Транзакция у тебя открыта на клиенте или на сервере?

IT>>Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

AVK>Так, тогда объясни мне что такое референс.

Референс — это ссылка

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

IT>>А это были не мои проблемы.

AVK>Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

Что именно доказать?

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

IT>>Не надо выворачивать. Я ничего не говорил о наличии/отсутствии объектных запросов в стайтлес модели.

AVK>А зачем тогда вобще их обсуждать, выставляя как преимущество стейтлес? Если вы о стейтлес то не надо вобще про это упоминать. Если же нет — так и скажи, я не буду встревать.

Ты опять что-то путаешь. Это не преимущество stateless, это недостаток stateful.

IT>>Что здесь не так? К тому же чем ближе к клиенту, тем уже более обработаны данные. Или тебе еще раз привести пример с браузером?

AVK>А чем дальше от клиента тем больше и эффективнее может заполняться кеш. Вобщем не надо обобщать

А ты уверен, что такой малоэффективный кэш вообще нужен? Часто изменяемые данные лучше всего кешируются самим sql сервером и не как объекты, а как сырые страницы файла данных.

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

AVK>>1 транзакция? Одним клиентом конечно. Попытка влезть из другой транзакции немедленно вызывает исключение. Насчет одной машины не понял.

IT>Транзакция у тебя открыта на клиенте или на сервере?

Клиентом на сервере

IT>>>Не, буз референса мне его секретарша ответит или спам фильтр отфильтрует.

AVK>>Так, тогда объясни мне что такое референс.

IT>Референс — это ссылка

IT>>>А это были не мои проблемы.

AVK>>Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

IT>Что именно доказать?

Что невозможно создать идеально масштабируемую архитектуру

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>Да я не спорю. Я против обобщения что клиентский кеш всегда лучше.

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

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

IT>>Транзакция у тебя открыта на клиенте или на сервере?

AVK>Клиентом на сервере

И используется только этим клиентом. Ну наконец-то

Тогда у меня вопрос. А нафига козе баян? Идея хранить данные на сервере, которые нужны только одному клиенту, конечно оригинальна, ничего не скажешь, но я кроме как ошибкой такой дизайн никак назвать не могу

IT>>Референс — это ссылка

Так вот я у тебя его и прошу

AVK>>>Вот видишь — ты заранее оговорил что использование твоих сервисов из джавы ты не закладываешь. ЧТо и требовалось доказать.

IT>>Что именно доказать?

AVK>Что невозможно создать идеально масштабируемую архитектуру

Т.е. "невозможно создать идеально масштабируемую архитектуру" потому что java плохо работает с вебсервисами? Найс.

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

AVK>>А зачем тогда вобще их обсуждать, выставляя как преимущество стейтлес? Если вы о стейтлес то не надо вобще про это упоминать. Если же нет — так и скажи, я не буду встревать.

IT>Ты опять что-то путаешь. Это не преимущество stateless, это недостаток stateful.

Это ты чего то путаешь. Это вобще не имеет отношения к модели.

AVK>>А чем дальше от клиента тем больше и эффективнее может заполняться кеш. Вобщем не надо обобщать

IT>А ты уверен, что такой малоэффективный кэш вообще нужен?

Ну напиши МС чтобы убрали кеш из MSSQL.

... << RSDN@Home 1.1.2 beta 2 >>

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

M>>Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями.
H_D>Ну, SQL тоже не боги писали... да и пишут

Это да. Но если учесть, что они в два раза менее профессиональнее тебя и у них уходит аж 4 часа на написание b-дерева, то представляешь сколько b-деревьев они за несколько понаписали

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

IT>И используется только этим клиентом. Ну наконец-то

IT>Тогда у меня вопрос. А нафига козе баян? Идея хранить данные на сервере, которые нужны только одному клиенту,

И рантайму сервера для обеспечения long running транзакций

AVK>>Ну можешь написать референс на меня, если поможет

IT>Так вот я у тебя его и прошу

А как это должно выглядеть с моей стороны?

AVK>>Что невозможно создать идеально масштабируемую архитектуру

IT>Т.е. "невозможно создать идеально масштабируемую архитектуру" потому что java плохо работает с вебсервисами? Найс.

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

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Ты опять что-то путаешь. Это не преимущество stateless, это недостаток stateful.

AVK>Это ты чего то путаешь. Это вобще не имеет отношения к модели.

Расскажи это ГВ и Хакеру

IT>>А ты уверен, что такой малоэффективный кэш вообще нужен?

AVK>Ну напиши МС чтобы убрали кеш из MSSQL.

Ну такого наглого выдёргивания из контекста я ещё не видел

А ты уверен, что такой малоэффективный кэш вообще нужен? Часто изменяемые данные лучше всего кешируются самим sql сервером и не как объекты, а как сырые страницы файла данных.

Андрей, как тебе не стыдно!

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

IT>>И используется только этим клиентом. Ну наконец-то

IT>>Тогда у меня вопрос. А нафига козе баян? Идея хранить данные на сервере, которые нужны только одному клиенту,

AVK>И рантайму сервера для обеспечения long running транзакций

Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

IT>>Так вот я у тебя его и прошу

AVK>А как это должно выглядеть с моей стороны?

Нужет e-mail или телефон, который знает Стив и который сможет по нему однозначно тебя по нему отождествить

AVK>>>Что невозможно создать идеально масштабируемую архитектуру

IT>>Т.е. "невозможно создать идеально масштабируемую архитектуру" потому что java плохо работает с вебсервисами? Найс.

AVK>Нет, потому что нельзя заранее предусмотреть всех необходимостей.

Блин, всё, надоело

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

AVK>>Ну напиши МС чтобы убрали кеш из MSSQL.

IT>Ну такого наглого выдёргивания из контекста я ещё не видел

IT>

IT>А ты уверен, что такой малоэффективный кэш вообще нужен? Часто изменяемые данные лучше всего кешируются самим sql сервером и не как объекты, а как сырые страницы файла данных.

IT>Андрей, как тебе не стыдно!

Нет, я не понял, а чем кеш на sql лучше кеша в сервере приложений?

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>И рантайму сервера для обеспечения long running транзакций

IT>Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

А кто тогда откатывать или коммитить в БД будет?

... << RSDN@Home 1.1.2 beta 2 >>

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

M>>>Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями.
H_D>>Ну, SQL тоже не боги писали... да и пишут

IT>Это да. Но если учесть, что они в два раза менее профессиональнее тебя и у них уходит аж 4 часа на написание b-дерева, то представляешь сколько b-деревьев они за несколько понаписали

Не, у них скорее всего месяца полтора на новое b-дерево уйдёт. И одних маркетинговых исследований — миллиона на два баксов.

Типа, чтобы доказать, что новое b-дерево зашибёт Sun, IBM и Oracle вместе взятых.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

AVK>А кто тогда откатывать или коммитить в БД будет?

А кто их сейчас коммитит?

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

TK>Были американцы на луне или нет, но сейчас обсуждение stateless vs statefull выглядит так: со стороные stateless есть конкретные технологии и готовые программные продукты. Со стороны statefull есть лишь абстрактный апп сервер который может все по определению (с максимальной эффенктивностью). Вобщем — хотелось-бы видеть конкретные продукты и приимеры реализации. Может тогда и вопросы сами собой отпадут?

У MS со stateful, действительно, НЕ СРОСЛОСЬ. Но это не значит, что у других то же самое.
Что-нибудь слышали о Sun J2EE? В EJB, в частности Stateful Session Bean, Вам не о чём не говорит.

TK>Вот например сервер без GC. Замечательно — давайте рассмотрим stateless vs COM+ и реализация бизнес объектов на С++?

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

IT>>>Так дело всё в том, что эти транзакции создаются только с одной целью — создать эти транзакции. Ни какой реальной необходимости в них нет.

AVK>>А кто тогда откатывать или коммитить в БД будет?

IT>А кто их сейчас коммитит?

Сервер приложений, точнее его подсистема управления длинными транзакциями. Или ты предлагаешь транзакции поднимать сразу в БД?

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ> Типа, чтобы доказать, что новое b-дерево зашибёт Sun, IBM и Oracle вместе взятых.

Гы, но весь прикол в том, что в итоге действительно зашибает..

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

ZEN>>Что скажете? Интересно было бы послушать альтернативщиков платформы MS, прежде всего из стана Java.
AS>Слушаем тебя с нетерпением.

Не подменяйте посылку.

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

AVK>>Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят?

IT>Говорят о тормознутости. Говорят об использовании мощных и дорогих санов для того чтобы это хоть как-то дышало. Говорят о системах под ключ стоимостью в десятки раз больше чем аналогичные для Windows.

Скажите это тем бедолагам, которые корчатся в муках, отлаживая свои творения в JBuilder, WebSphere, JDeveloper и др. Из Ваших слов очевидно, что им давно пора застрелиться. Ан нет, что-то ковыряют в EJB, отлаживают на локальных машинах.

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

IT>>Она у меня уже есть по умолчанию. Называется веб-сервисы

AVK>Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем

После прочтения вот этого http://ru.sun.com/pdf/j2ee/WST.pdf будет ли смешно?

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

ГВ>> Типа, чтобы доказать, что новое b-дерево зашибёт Sun, IBM и Oracle вместе взятых.

M>Гы, но весь прикол в том, что в итоге действительно зашибает..

Ну, значит, славный баобаб получился.

... << RSDN@Home 1.1.2 beta 2 >>

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

ZEN>Скажите это тем бедолагам, которые корчатся в муках, отлаживая свои творения в JBuilder, WebSphere, JDeveloper и др. Из Ваших слов очевидно, что им давно пора застрелиться. Ан нет, что-то ковыряют в EJB, отлаживают на локальных машинах.

Тёмные оне, не просвещённые. Да и делать лёгкий, быстрый софт совсем не в их интересах. Если они будут быстро и качественно писать, то чем они будут обосновывать такие цены на свои продукты.
Боюсь что после их санов им уже ничего не поможет

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

IT>>А кто их сейчас коммитит?

AVK>Сервер приложений, точнее его подсистема управления длинными транзакциями. Или ты предлагаешь транзакции поднимать сразу в БД?

Я для начала хочу понять какими были первоначальные требования. Пока у меня сложилась следующая картина. Баба Маня вводит документ и он уходит на сервер, на сервере он живёт до тех пор, пока баба Маня возится с другими его частями, после чего говорит "Огонь" и весь этот паровоз едет в базу данных. Правильно?

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Я для начала хочу понять какими были первоначальные требования. Пока у меня сложилась следующая картина. Баба Маня вводит документ и он уходит на сервер, на сервере он живёт до тех пор, пока баба Маня возится с другими его частями, после чего говорит "Огонь" и весь этот паровоз едет в базу данных. Правильно?

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

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

AVK>Даже хуже. Баба Маня вводит не один документ, а несколько связанных. Причем логика взаимодействия этих документов и предварительных расчетов (например посчитать сумму по больничному) должна быть на сервере, это не обсуждается, это часть ТЗ. Но эта же логика должна отработать до завершения транзакции и быть показана бабе Мане (чтобы она поглядела эту самую сумму). Продолжительность ввода бабой Маней этой кучи документов может быть большой. При отказе или сбое машины вся куча должна быть откачена. Вот такие вот вводные.

Понял. Моё решение могло бы быть таким.
Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает. Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

Stateless в чистом виде

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

AVK>>Даже хуже. Баба Маня вводит не один документ, а несколько связанных. Причем логика взаимодействия этих документов и предварительных расчетов (например посчитать сумму по больничному) должна быть на сервере, это не обсуждается, это часть ТЗ. Но эта же логика должна отработать до завершения транзакции и быть показана бабе Мане (чтобы она поглядела эту самую сумму). Продолжительность ввода бабой Маней этой кучи документов может быть большой. При отказе или сбое машины вся куча должна быть откачена. Вот такие вот вводные.

IT>Понял. Моё решение могло бы быть таким.
IT>Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.

IT>Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>Stateless в чистом виде

То-то и оно, что stateless, да ещё и с разгруженным SQL-сервером. Сначала тебе нужно гонять избранные фрагменты (которые нужно программить вручную) для обсчёта промежуточных величин, а потом — полное тело документа. Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п. Плюс — продублировать вычисления после отправки завершённого документа.

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

IT>Понял. Моё решение могло бы быть таким.
IT>Баба Маня вводит документы локально.

Опаньки. Значит состояние надо на клиенте держать? Проблемы перечислить или и так понятно?

IT>При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

Абалдеть. ООП в действии

. Данные отдельно, алгоритмы отдельно. Только вот нифига не выйдет так — в алгоритмах рассчетов практически всегда фигурируют только что введенные данные. Единственный способ в таком варианте — гнать данные на сервер. Это тот самый случай когда стейтлес вносит жуткий оверхед, что и требовалось доказать.

IT> Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу.

А если в процессе ввода документов нужно автоматически добавлять какие то объекты? На клиенте добавлять? Но это ведб БЛ, а она допустима только на сервере!

IT> Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>Stateless в чистом виде

Ага.

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

H_D>Слушай! У меня именно такие требования быви в одной из работ...
H_D>Так что ты привел вполне жизненый пример..
H_D>комментарий: бабу Маню млжет звали Дусей, но у нее было 4 класса образования и слово из 15 символов она вводила минуты 3-4...

Баба Маня или Дуся — это непременное негласное требование любого ТЗ.

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

IT>>Понял. Моё решение могло бы быть таким.
IT>>Баба Маня вводит документы локально.

AVK>Опаньки. Значит состояние надо на клиенте держать? Проблемы перечислить или и так понятно?

Начинай

IT>>При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

AVK>Абалдеть. ООП в действии

.

Ага, ты мне ещё про полиморфик бихейвор расскажы

Дон Бокс тебе же ясно сказал — ООП идёт лесом

AVK>Данные отдельно, алгоритмы отдельно.

Точно.

AVK>Только вот нифига не выйдет так — в алгоритмах рассчетов практически всегда фигурируют только что введенные данные.

Почему? Данные же были введены отдельно от алгоритмов

AVK>Единственный способ в таком варианте — гнать данные на сервер. Это тот самый случай когда стейтлес вносит жуткий оверхед, что и требовалось доказать.

Ну если гнать бездумно, то и доказывать не надо. К тому же ты и так всё гонишь, документы на сервере ведь не в огороде рождаются.

IT>> Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу.

AVK>А если в процессе ввода документов нужно автоматически добавлять какие то объекты? На клиенте добавлять?

Зависит от задачи. Дай мне больше информации, я тебе дам ответ на твой вопрос.

AVK>Но это ведб БЛ, а она допустима только на сервере!

Кто тебе сказал? Я уже говрил, валидация — это часть БЛ, но должна выполнятся в том числе и на клиенте во избежании раунд-трипов.

IT>> Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>>Stateless в чистом виде

AVK>Ага.

Дык

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

IT>>Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

ГВ>Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.

Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

IT>>Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>>Stateless в чистом виде

ГВ>То-то и оно, что stateless, да ещё и с разгруженным SQL-сервером.

А тебе нужен stateful с загруженным?

ГВ>Сначала тебе нужно гонять избранные фрагменты (которые нужно программить вручную) для обсчёта промежуточных величин, а потом — полное тело документа.

А у тебя есть конкретная информация об этих самых величинах? Может там всего лишь надо посчитать НДС от заданной суммы. Восемь байт туда, восемь сюда. Какие проблемы? Вот когда АВК расколется, тогда и будем об этом рассуждать.

ГВ>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.

Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

ГВ>Плюс — продублировать вычисления после отправки завершённого документа.

Зависит.

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

AVK>Причем логика взаимодействия этих документов и предварительных расчетов (например посчитать сумму по больничному) должна быть на сервере, это не обсуждается, это часть ТЗ.

Кстати, давно хотел тебя спросить

А "логика на сервере" как часть ТЗ — это круто. Где такого заказчика нашёл? Как минимум товарищ должен быть очень не слабо технически подкован, что бы решать такие вопросы. Уж не ты ли его подковывал?

IT>Где такого заказчика нашёл? Как минимум товарищ должен быть очень не слабо технически подкован, что бы решать такие вопросы. Уж не ты ли его подковывал?

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

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

AVK>>Опаньки. Значит состояние надо на клиенте держать? Проблемы перечислить или и так понятно?

IT>Начинай

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

IT>>>При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

AVK>>Абалдеть. ООП в действии

.

IT>Ага, ты мне ещё про полиморфик бихейвор расскажы

IT>Дон Бокс тебе же ясно сказал — ООП идёт лесом

А я не пионер чтобы безоговорочно верить вождям революции.

AVK>>Только вот нифига не выйдет так — в алгоритмах рассчетов практически всегда фигурируют только что введенные данные.

IT>Почему? Данные же были введены отдельно от алгоритмов

Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

AVK>>Единственный способ в таком варианте — гнать данные на сервер. Это тот самый случай когда стейтлес вносит жуткий оверхед, что и требовалось доказать.

IT>Ну если гнать бездумно, то и доказывать не надо.

А не бездумно это как?

IT> К тому же ты и так всё гонишь, документы на сервере ведь не в огороде рождаются.

Я это делаю один раз, а не каждый раз когда мне пересчитать надо.

IT>>> Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу.

AVK>>А если в процессе ввода документов нужно автоматически добавлять какие то объекты? На клиенте добавлять?

IT>Зависит от задачи. Дай мне больше информации, я тебе дам ответ на твой вопрос.

Не зависит от задачи. Клиент должен быть универсальным и никак не зависеть от конкретного приложения. Писать специализированного клиента под каждую задачку никто не будет.

AVK>>Но это ведб БЛ, а она допустима только на сервере!

IT>Кто тебе сказал?

Начальник сказал. Тебя так устроит? Или будем дискутировать о допустимости бизнес-логики на клиенте? Но это уже спор не о модели хранения состояний, а о самой структуре n-tier. Если твоя замечательная архитектура приводит к различным извращениям вроде регулярной транспортировки состояний и выносу БЛ на клиента то это проблемы твоей архитектуры и очень странно что ты этих проблем не видишь.

IT> Я уже говрил, валидация — это часть БЛ, но должна выполнятся в том числе и на клиенте во избежании раунд-трипов.

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

AVK>>Ага.

IT>Дык

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

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

ГВ>>Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.

IT>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

У меня есть — логика и данные на сервере

. На клиенте только интерфейс.

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

Ох IT, не одним НДС все обходится.

IT>Вот когда АВК расколется, тогда и будем об этом рассуждать.

Я тебе уже сказал — давай обсудим предварительные расчеты больничных и отпусков. Типовая задачка в зарплате.

ГВ>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.

IT>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

И вся правка на смарку? Замечательно.

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

IT>>>Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.
ГВ>>Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.
IT>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

Логика и данные на сервере (серверах). На клиенте — только презентация.

IT>>>Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.
IT>>>Stateless в чистом виде

ГВ>>То-то и оно, что stateless, да ещё и с разгруженным SQL-сервером.
IT>А тебе нужен stateful с загруженным?

От stateless мне ничего н нужно.

Разгрузка SQL-сервера в твоём случае означает вытаскивание колтуна из логики и состояний на клиента.

ГВ>>Сначала тебе нужно гонять избранные фрагменты (которые нужно программить вручную) для обсчёта промежуточных величин, а потом — полное тело документа.
IT>А у тебя есть конкретная информация об этих самых величинах? Может там всего лишь надо посчитать НДС от заданной суммы. Восемь байт туда, восемь сюда. Какие проблемы? Вот когда АВК расколется, тогда и будем об этом рассуждать.

Он уже раскололся.

Кстати, величина НДС от заданной суммы тожет зависит от разных величин. Зависело, во всяком случае... правда, последних изменений в законодательстве на эту тему я не знаю.

Да и твои 8 байт сюда 8 сюда на практике всё равно превратятся примерно в килобайт.

ГВ>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.
IT>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

И что ты собираешься в блоке catch писать?

ГВ>>Плюс — продублировать вычисления после отправки завершённого документа.
IT>Зависит.

Не-а, поскольку тебе обязательно нужно убедиться, что данные не перекорёжены по пути, что клиенсткие скрипты отработали правильно и т.д., и т.п.

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

IT>Ага, ты мне ещё про полиморфик бихейвор расскажы

IT>Дон Бокс тебе же ясно сказал — ООП идёт лесом

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

... << RSDN@Home 1.1.2 beta 2 >>

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

AVK>>Во-первых насчет нескольких раз ты перебрал, а во-вторых по твоему сложные проверки легче писать не на шарпе, а на tsql, так что ли?

AS>Конечно, нет. Я лишь говорю, что все проверки ограничений целостности, уникальности и другие обязаны присутствовать в sql-сервере, даже если они дублируются на коде бизнес-логики и на клиенте.

Нет, не все и не всегда. Всё зависит от того, как использутся SQL-сервер. Если кроме App-сервера в одну и ту же базу лезет ещё два десяька модулей (они же — сервисы и проч.), то делать нечего — надо тащить в SQL-сервер всё подряд, хотя бы для того, чтобы не дублировать БЛ сервисов и App-сервера (его прикладных компонент). А если работаешь "по-грамотному", то есть, App-сервер — это единственный "шлюз" в базу данных, то... короче говоря, всё подряд в него абсолютно необязательно пихать.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

AVK>У меня есть — логика и данные на сервере

. На клиенте только интерфейс.

Это уже веб-браузер получается. Самый тонкий клиент в мире

IT>>Вот когда АВК расколется, тогда и будем об этом рассуждать.

AVK>Я тебе уже сказал — давай обсудим предварительные расчеты больничных и отпусков. Типовая задачка в зарплате.

Непременно обсудим

IT>>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

AVK>И вся правка на смарку? Замечательно.

Зачем же так жестоко. Исключение выброшенное на сервере обычно обрабатывается клиентом, который докладывает бабе Мане, в чём именно она не права.

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

IT>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

ГВ>Логика и данные на сервере (серверах). На клиенте — только презентация.

А презентация у тебя что отображает? Банеры что ли

IT>>А тебе нужен stateful с загруженным?

ГВ>От stateless мне ничего н нужно.

Разгрузка SQL-сервера в твоём случае означает вытаскивание колтуна из логики и состояний на клиента.

Простите, вытаскивание кого?

ГВ>Да и твои 8 байт сюда 8 сюда на практике всё равно превратятся примерно в килобайт.

Всё зависит от задачи, я предпочитаю взвешенный подход (с) АВК

ГВ>>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.
IT>>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

ГВ>И что ты собираешься в блоке catch писать?

Показывать бабе Мане что произошло.

ГВ>>>Плюс — продублировать вычисления после отправки завершённого документа.
IT>>Зависит.

ГВ>Не-а, поскольку тебе обязательно нужно убедиться, что данные не перекорёжены по пути, что клиенсткие скрипты отработали правильно и т.д., и т.п.

Что значит перекорёжены по пути? Кабель что ли перекручен или где-то на него водопровод протекает?

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

IT>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

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

Как это не печально, но его прежде всего интересует то, что ты будешь использовать через несколько лет.

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

IT>>Где такого заказчика нашёл? Как минимум товарищ должен быть очень не слабо технически подкован, что бы решать такие вопросы. Уж не ты ли его подковывал?

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

Фирма чья?

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

AVK>Необходимость гонять его на сервер,

Что-то гонять по любому приходится. Вопрос только в том, как это минимизировать.

AVK>крайняя сложность поддержания актуального состояния

Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.

AVK>вынос логики управления длинными транзакциями на клиента,

Ничего страшного.

AVK>низкая надежность.

Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт

Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?

AVK>>>Абалдеть. ООП в действии

.

IT>>Ага, ты мне ещё про полиморфик бихейвор расскажы

IT>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

AVK>А я не пионер чтобы безоговорочно верить вождям революции.

Раз мы не пионеры, то давай не будем друг друга лечить всякими лозунгами про ООП. Когда он мне помогает, я его применяю не хуже тебя. Когда мещает, то идёт лесом под барабанную дробь Дона Бокса. Правда, надо признать, таких ситуаций почти не бывает (даже не взирая на слова Бокса

).

AVK>Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

Зависит от задачки

(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте. Насколько мне известно, все зарплаты, которые я когда либо видел и делал, работают именно по такому принципу. А вот пакетный расчёт можно делать и на сервере.

IT>>Ну если гнать бездумно, то и доказывать не надо.

AVK>А не бездумно это как?

Зависит от задачки

AVK>Не зависит от задачи. Клиент должен быть универсальным и никак не зависеть от конкретного приложения. Писать специализированного клиента под каждую задачку никто не будет.

Универсальный клиент — это веб-браузер. Можно сделать менее универсальный, который будет хостить определённые расчитанные на него UI-модули. Можно сделать специализированный фрэймворк и соответственно уменьшить затраты на разработку самих модулей. Можно вообще ничего не универсиализировать. Но в любом случае, чем более или менее универсальнее твой UI-хост, тем больше писать кода в UI. Наилучший вариант где-то посередине. Так что зависит.

IT>>Кто тебе сказал?

AVK>Начальник сказал. Тебя так устроит? Или будем дискутировать о допустимости бизнес-логики на клиенте? Но это уже спор не о модели хранения состояний, а о самой структуре n-tier.

Об этом тоже можно поспорить. Всё зависит от задачки... ну ты знаешь

AVK>Если твоя замечательная архитектура приводит к различным извращениям вроде регулярной транспортировки состояний и выносу БЛ на клиента то это проблемы твоей архитектуры и очень странно что ты этих проблем не видишь.

Моей архитектуре пока этого не надо. Но если задача потребует, то я не буду сильно из-за этого горевать. Любая теория хороша до тех пор пока она подтверждается практикой. Как только возникает конфликт, то чаще всего меняется теория.

IT>> Я уже говрил, валидация — это часть БЛ, но должна выполнятся в том числе и на клиенте во избежании раунд-трипов.

AVK>Какая к черту валидация. Нужно считать и создавать новые объекты по ходу ввода документа. Документы не заканчиваются примитивными накладными, которые легко упихать в стейтлес-модель. Докуенты могут иметь очень сложную структуру с кучей подчиненных.

Вот то-то и оно.

IT>>Дык

AVK>Дык вот я тебя и поймал — ты очень наглядно продемонстрировал плохую применимость стейтлес модели для подобных задачек.

Должен тебя огорчить. К твоему сожалению, ты меня не поймал, а сам попался в искусно расставленные сети

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

Вот о ней и поговорим.

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

Круто!

Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере. Любой стэйтфул не надёжен по определению, т.к. память пока является самым ненадёжным хранилищем данных. Всё это помножается на ненадёжность сети и локальной машины, сложность ПО и поддержки. Если хранить документ в памяти локального компьютера, то он конечно тоже в памяти, но пользователь чётко знает и видит, что происходит. Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless. Подготовка (сколь угодно сложная) документа на клиенте, запрос к серверу, обработка данных сервером приложений, сохранение данных в базе, возврат пользователю информации об успешности транзакции. Всё просто, надёжно и быстро. Каждая часть системы занимается своим делом, тем для чего она предназначена и что у неё лучше получается.

Ты же явно перемудрил. То что ты называешь длинными транзакциями на самом деле называется режимом Undo/Redo. Ничего необычного. Правда иногда сложно реализуется для сложных документов.

Логика для таких задач практически не формализуется и меняется настолько часто, что её нужно выность не то что в БЛ, а вообще из кода проекта. Необходимо либо задействовать скрипты, либо подключаемые обновляемые модули. Переписывать БЛ под каждый чих правительсьтва — это чушь. 10 лет назад мы делали свой С-подобный язык, хранили скрипты в базе и подгружали их по мере необходимости. Сейчас существуют более продвинутые технологии. В качестве скриптового языка можно задействовать любой язык .NET или сразу все. Да ты и сам это знаешь не хуже меня. Можно хранить такие скрипты в виде текста или же подгружать сборки с обновлениями. Но в любом случае, это лучше делать на клиенте. На сервере они тоже пригодятся для пакетных расчётов, но перерасчёт во время ввода данных на сервер отдавать совершенно нет никакого резона (если этот расчёт при вводе данных вообще нужен).

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

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

В общем, я могу понять только один твой аргумент — так сказал начальник. Ну что же, передавай ему от меня большой stateful привет!

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

IT>>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

ГВ>>Логика и данные на сервере (серверах). На клиенте — только презентация.
IT>А презентация у тебя что отображает? Банеры что ли

Только то, что определено приложением, как доступное пользователю для просмотра или редактирования.

IT>>>А тебе нужен stateful с загруженным?
ГВ>>От stateless мне ничего н нужно.

Разгрузка SQL-сервера в твоём случае означает вытаскивание колтуна из логики и состояний на клиента.
IT>Простите, вытаскивание кого?

Колтуна.

Когда состояние полностью дублируется на клиенте. Собственно, "колтуном" я это назвал, не потому, что вытаскивается на клиента, а потому что придётся скорее всего вручную всё это выписывать.

ГВ>>Да и твои 8 байт сюда 8 сюда на практике всё равно превратятся примерно в килобайт.
IT>Всё зависит от задачи, я предпочитаю взвешенный подход (с) АВК

Да, естественно. Только вот минимальный размер IP-пакета, если мне не изменяет память, всё-таки 60 байт, а если ещё и соединение переоткрывать... а если ещё http...

ГВ>>>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.
IT>>>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

ГВ>>И что ты собираешься в блоке catch писать?
IT>Показывать бабе Мане что произошло.

Это-то понятно, а с приложением что ты делать собираешься?

ГВ>>>>Плюс — продублировать вычисления после отправки завершённого документа.
IT>>>Зависит.
ГВ>>Не-а, поскольку тебе обязательно нужно убедиться, что данные не перекорёжены по пути, что клиенсткие скрипты отработали правильно и т.д., и т.п.
IT>Что значит перекорёжены по пути? Кабель что ли перекручен или где-то на него водопровод протекает?

И это тоже. Ошибки и при упаковке могут быть, и при распаковке, особенно, если их вручную писать.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

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

Ну уж на таком уровне это не Дону Боксу это решать.

Хотя, из того, что будет использоваться кое-что может оказаться и вышедшим из-под его руки, почему бы и нет?

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>Фирма чья?

В которой я раюотаю

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

AVK>>крайняя сложность поддержания актуального состояния

IT>Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.

А сам документ может данные тягать из других документов.

AVK>>вынос логики управления длинными транзакциями на клиента,

IT>Ничего страшного.

Ну если тебе не страшно тогда собственно дальше говорить не о чем. У меня подходы другие. Доверять управление транзакциями клиенту для меня неприемлемо.

AVK>>низкая надежность.

IT>Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт

Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?

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

IT>>>Ага, ты мне ещё про полиморфик бихейвор расскажы

IT>>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

AVK>>А я не пионер чтобы безоговорочно верить вождям революции.

IT>Раз мы не пионеры, то давай не будем друг друга лечить всякими лозунгами про ООП.

А где я тебя лозунгами лечил? Ты наверное меня с кем то спутал.

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

).

А вот у меня как раз больше ситуаций когда идеи Бокса идут лесом. В этом и проблема.

AVK>>Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

IT>Зависит от задачки

Ты читаешь внимательно? Задача — рассчет больничного.

IT>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.

Т.е. БЛ на клиенте? Ну в общем дальше я обсуждать не хочу, поскольку, как я уже говорил, это для меня неприемлемо в принципе. Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость.

IT> Насколько мне известно, все зарплаты, которые я когда либо видел и делал, работают именно по такому принципу.

Ну значит ты не делал зарплату на трехзвенке.

IT> А вот пакетный расчёт можно делать и на сервере.

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

AVK>>Не зависит от задачи. Клиент должен быть универсальным и никак не зависеть от конкретного приложения. Писать специализированного клиента под каждую задачку никто не будет.

IT>Универсальный клиент — это веб-браузер.

И это верно. Но вот только не всегда веб-интерфейс прокатывает.

IT> Можно сделать менее универсальный, который будет хостить определённые расчитанные на него UI-модули.

Так и делается.

IT>Но в любом случае, чем более или менее универсальнее твой UI-хост, тем больше писать кода в UI. Наилучший вариант где-то посередине. Так что зависит.

Зависит. В моем случае, если тебе интересно, приложений будет большое количество. Отсюда и требование универсального клиента.

AVK>>Начальник сказал. Тебя так устроит? Или будем дискутировать о допустимости бизнес-логики на клиенте? Но это уже спор не о модели хранения состояний, а о самой структуре n-tier.

IT>Об этом тоже можно поспорить.

Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.

AVK>>Если твоя замечательная архитектура приводит к различным извращениям вроде регулярной транспортировки состояний и выносу БЛ на клиента то это проблемы твоей архитектуры и очень странно что ты этих проблем не видишь.

IT>Моей архитектуре пока этого не надо.

Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.

IT>О сложности самой задачи мне рассказвать не надо. Первый раз я с ней столкнулся больше 10 лет назад. Да, действительно, задача сложная и слабоформализуемая благодаря неожиданности российского законодательства и многообразию необходимых данных. Скорее всего, самая тяжёлая из бухгалтерских задач. Далше только склад.

Да нет, со складом свои, другие заморочки.

IT>Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано.

Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.

IT>Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере.

Давай не будем передергивать.

IT> Любой стэйтфул не надёжен по определению, т.к. память пока является самым ненадёжным хранилищем данных.

Так батенька даже sql-сервер данные хранит в том числе и в памяти. Вот только память на сервере куда надежнее памяти на клиенте.
IT>Если хранить документ в памяти локального компьютера, то он конечно тоже в памяти, но пользователь чётко знает и видит, что происходит.

Вот только не надо переходить на демагогию. При чем тут понимание пользователя? Пользователю плевать где и что хранится.

IT> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.

Точно так же и в стейтфул.

IT>Ты же явно перемудрил. То что ты называешь длинными транзакциями на самом деле называется режимом Undo/Redo.

Ага, со вложенностью, многоуровневый, версионный и с автоматическим откатом только. А так да, обычный Undo/Redo

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

AVK>>У меня есть — логика и данные на сервере

. На клиенте только интерфейс.

IT>Это уже веб-браузер получается. Самый тонкий клиент в мире

Эк у тебя однобоко. Если тонкий клиент так сразу браузер. Тонкие GUI клиенты тоже имеют право на существование.

... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>

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

IT>>>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

AVK>>>У меня есть — логика и данные на сервере

. На клиенте только интерфейс.
IT>>Это уже веб-браузер получается. Самый тонкий клиент в мире

AVK>Эк у тебя однобоко. Если тонкий клиент так сразу браузер. Тонкие GUI клиенты тоже имеют право на существование.

Я скажу больше — существуют и не в единственном экземпляре.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>>И что ты собираешься в блоке catch писать?
IT>>Показывать бабе Мане что произошло.

ГВ>Это-то понятно, а с приложением что ты делать собираешься?

А это уже бабе Мане решать.

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

IT>>Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.

AVK>А сам документ может данные тягать из других документов.

А эти документы кто-то редактирует в данный момент?

AVK>Ну если тебе не страшно тогда собственно дальше говорить не о чем. У меня подходы другие. Доверять управление транзакциями клиенту для меня неприемлемо.

Боюсь что ты путаешь тёплое с мягким.

IT>>Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт

Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?

AVK>При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера.

Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?

AVK>>>Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

IT>>Зависит от задачки

AVK>Ты читаешь внимательно? Задача — рассчет больничного.

... и от того как её решать.

IT>>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.

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

По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.

AVK>Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость.

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

AVK>Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.

Для твоей задачки оно вполне приемлемо.

AVK>Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.

Обобщения чего? Того что stateless для подавляющего числа задач лучше? Так это и ёжику понятно. Вот только ты один упёрся и не хочешь этого признать.

IT>>Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано.

AVK>Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.

Почему-то у нас это раньше получалось без постоянного переписыания приложений

IT>>Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере.

AVK>Давай не будем передергивать.

А я не передёргиваю. Я тебе просто пытаюсь объяснить, что ты решаешь задачу неверным способом.

IT>> Любой стэйтфул не надёжен по определению, т.к. память пока является самым ненадёжным хранилищем данных.

AVK>Так батенька даже sql-сервер данные хранит в том числе и в памяти. Вот только память на сервере куда надежнее памяти на клиенте.

В памяти он их кэширует. А хранит он их на диске. Чувствуешь разницу?

IT>> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.

AVK>Точно так же и в стейтфул.

В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.

IT>>Ты же явно перемудрил. То что ты называешь длинными транзакциями на самом деле называется режимом Undo/Redo.

AVK>Ага, со вложенностью, многоуровневый, версионный и с автоматическим откатом только. А так да, обычный Undo/Redo

О! Начинаешь соображать

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

IT>>Фирма чья?

AVK>В которой я раюотаю

И ТЗ писалось без твоего участия?

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

ГВ>>>>И что ты собираешься в блоке catch писать?
IT>>>Показывать бабе Мане что произошло.
ГВ>>Это-то понятно, а с приложением что ты делать собираешься?

IT>А это уже бабе Мане решать.

Смешно.

Уже вижу бабу Маню с дебуггером в руках.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>>Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.
AVK>>А сам документ может данные тягать из других документов.
IT>А эти документы кто-то редактирует в данный момент?

А почему бы и нет? Если объекты "живут" на App-сервере, то такая задача вполне решаема (если сие нужно, конечно).

[...]

IT>>>Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт

Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?
AVK>>При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера.
IT>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?

Провисит себе объект до следующего соединения этого же клиента и всё — продолжит клиент юзер с того места, на котором его застигла стихия. Ну, или будет убран по истечении таймаута с откатом транзакции. Вариантов — вагон.

[...]

IT>>>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.
AVK>>Т.е. БЛ на клиенте? Ну в общем дальше я обсуждать не хочу, поскольку, как я уже говорил, это для меня неприемлемо в принципе.
IT>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.

Странно. Если зашивать БЛ в хранимых процедурах, то это хорошо, если в в промежуточном слое — плохо, а если на клиенте, то опять хорошо. О, загадочная русская душа!

AVK>>Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость.
IT>Не лучший способ — это переписывать сервер приложений под каждое изменение законодательства.

Правильно, его лучше написать один раз. А кто говорил, что App-сервер переписывается? Переписывается БЛ. Кстати, это не отрицает того, о чём я тебе раньше говорил, что база данных по имени "App-сервер" есть специально спроектированная под задачу база данных. Просто нужно разделять две вещи: Ядро App-сервера и App-сервер, как совокупность БЛ и ядра, только и всего.

AVK>>Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.
IT>Для твоей задачки оно вполне приемлемо.

Хммм... задачка-то вполне неплохо иллюстрирует плюсы и минусы обоих подходов.

AVK>>Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.
IT>Обобщения чего? Того что stateless для подавляющего числа задач лучше? Так это и ёжику понятно.

Покажите мне того ёжика!

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

Не один.

Что за намёки?

IT>>>Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано.
AVK>>Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.
IT>Почему-то у нас это раньше получалось без постоянного переписыания приложений

Почему-то для stateful получается то же самое, что и для stateless — нужно отдеплоить новые модули, если не удаётся просто сконфигурировать старые в соответствии с новым законодательством.

IT>>>Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере.
AVK>>Давай не будем передергивать.
IT>А я не передёргиваю. Я тебе просто пытаюсь объяснить, что ты решаешь задачу неверным способом.

Как интересно.

Такой темы ещё не поднималось. Уже появились единственно верные способы решения? Я то всегда думал, что здесь есть только приемлемые или неприемлемые способы.

[...]

IT>>> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.
AVK>>Точно так же и в стейтфул.
IT>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.

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

Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. Юзер должен знать, что пока он не нажал на Save ему не желательно выключать свой компьютер, а после Save он уже может выключить свою машину (пролить на неё кофе, переустановить Windows...), включить заново и снова загрузить то, чему он сделал Save. Откуда придёт появится документ — из кэша App-сервера, с диска SQL-сервера и прочее — не имеет никакого значения.

... << RSDN@Home 1.1.2 beta 2 >>

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

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

ГВ>Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.
Вот это вот и есть промашка в дизайне.

ГВ>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы.
Тут еще есть один немаловажный момент.
Пока у тебя есть фиксация транзакции в памяти, то заказчик может только держать свечку УПС'у и молиться за всех электриков в округе. Но как только транзакция зафиксировалась на диске, то тут уже он сам в ответе за сохранность данных, он можт отмиррорить этот диск куда угодно, совершенно стандартными средствами, не зависящими от твоего приложения, и головой не болеть.

... [RSDN@Home 1.1.0 stable]

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

IT>>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?

ГВ>Провисит себе объект до следующего соединения этого же клиента и всё — продолжит клиент юзер с того места, на котором его застигла стихия.

А как ты клиента идентифицируешь? По логину? Т.е. ты собираешься гонять это каждый раз по сети?

ГВ>Ну, или будет убран по истечении таймаута с откатом транзакции. Вариантов — вагон.

А какой должен быть таймаут? Вдруг баба Маня решила доделать работу после обеда или вообще завтра, а завтра опа, баба Маня, вся твоя работа expired.

IT>>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.

ГВ>Странно. Если зашивать БЛ в хранимых процедурах, то это хорошо, если в в промежуточном слое — плохо, а если на клиенте, то опять хорошо. О, загадочная русская душа!

Во первых про SP это твои фантазии, я такого нигде не говорил. Во-вторых, БЛ о которой идёт речь настолько часто меняется, что должна сама быть имплементирована как часть данных системы. В этом случае куда её подгрузить и где выполнить нет никакой разницы.

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

ГВ>Не один.

Что за намёки?

Да-да, простите, двое вас

IT>>Почему-то у нас это раньше получалось без постоянного переписыания приложений

ГВ>Почему-то для stateful получается то же самое, что и для stateless — нужно отдеплоить новые модули, если не удаётся просто сконфигурировать старые в соответствии с новым законодательством.

Мда, оригинально.

IT>>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.

ГВ>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях.

Не твои ли слова?

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

ГВ>Вовсе не обязательно откладывать абсолютно все транзакции. Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.

Обязательно не откладывать ни одной.

ГВ>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. Юзер должен знать, что пока он не нажал на Save ему не желательно выключать свой компьютер, а после Save он уже может выключить свою машину (пролить на неё кофе, переустановить Windows...), включить заново и снова загрузить то, чему он сделал Save. Откуда придёт появится документ — из кэша App-сервера, с диска SQL-сервера и прочее — не имеет никакого значения.

Из кэша или сервера без разницы. Но ты говоришь не о кэше, а о хранилище в памяти апп-сервера, а это большая разница.

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

IT>>А это уже бабе Мане решать.

ГВ>Смешно.

Уже вижу бабу Маню с дебуггером в руках.

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

AVK>>А сам документ может данные тягать из других документов.

IT>А эти документы кто-то редактирует в данный момент?

Зависит от задачи

AVK>>Ну если тебе не страшно тогда собственно дальше говорить не о чем. У меня подходы другие. Доверять управление транзакциями клиенту для меня неприемлемо.

IT>Боюсь что ты путаешь тёплое с мягким.

Боюсь нет.

AVK>>При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера.

IT>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?

Либо сработают проверки, если клиент погонит пургу, либо все откатится.

IT>>>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.

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

IT>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.

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

AVK>>Но даже если так — тащить зарплату за несколько месяцев на клиента не лучший способ обеспечить масштабируемость.

IT>Не лучший способ — это переписывать сервер приложений под каждое изменение законодательства.

А его никто и не переписывает, переписывают БЛ.

AVK>>Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.

IT>Для твоей задачки оно вполне приемлемо.

Какой? Для зарплаты? IT, ты точно меня не понимаешь. Если бы у меня стояла задача написать зарплату то никто бы с трехзвенкой и не заморачивался бы. Задача стоит написать платформу для решения типовых проблем автоматизации малых и средних предприятий малыми силами.

AVK>>Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.

IT>Обобщения чего? Того что stateless для подавляющего числа задач лучше?

Именно, потому что для подавляющего большинства ТВОИХ задач.

IT>Так это и ёжику понятно. Вот только ты один упёрся и не хочешь этого признать.

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

AVK>>Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.

IT>Почему-то у нас это раньше получалось без постоянного переписыания приложений

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

AVK>>Так батенька даже sql-сервер данные хранит в том числе и в памяти. Вот только память на сервере куда надежнее памяти на клиенте.

IT>В памяти он их кэширует. А хранит он их на диске. Чувствуешь разницу?

Вот и сервер приложений в памяти кеширует, а хранит в БД, чувствуешь разницу?

IT>>> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.

AVK>>Точно так же и в стейтфул.

IT>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет.

С чего ты взял? Подтверждение он получит только когда пройдет успешный коммит транзакции, а это возможно только при успешной записи в БД.

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

Не пойму только при чем здесь стейтлес.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях.

IT>Не твои ли слова?

А не мне ли ты отвечал?

... << RSDN@Home 1.1.2 beta 2 >>

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

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

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

ГВ>>Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.
M>Вот это вот и есть промашка в дизайне.

Почему? Я получаю отклик "OK" от App-сервера, который в данный момент (данной конфигурации и т.п.) не использует отложенных транзакций, ergo данные занесены на диск SQL-сервера. В чём промашка?

ГВ>>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы.
M>Тут еще есть один немаловажный момент.
M>Пока у тебя есть фиксация транзакции в памяти, то заказчик может только держать свечку УПС'у и молиться за всех электриков в округе. Но как только транзакция зафиксировалась на диске, то тут уже он сам в ответе за сохранность данных, он можт отмиррорить этот диск куда угодно, совершенно стандартными средствами, не зависящими от твоего приложения, и головой не болеть.

Ничего, подержит. Или, глядишь, и головой подумает.

Ему по-любому над чем-нибудь, да надо будет "свечку держать": либо над UPS либо над винтами.

На всякий случай, ещё раз повторяю: откладывание транзакций — необязательно используемая возможность.

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>>Хорошо. Вот сбойнул у тебя клиент, что будет с объектом на сервере?
ГВ>>Провисит себе объект до следующего соединения этого же клиента и всё — продолжит клиент юзер с того места, на котором его застигла стихия.
IT>А как ты клиента идентифицируешь? По логину? Т.е. ты собираешься гонять это каждый раз по сети?

Не только по логину. Ещё и SessionID есть. Кстати, а сколько раз аналогичная информация из cookie или Session-storage кататься будет?

ГВ>>Ну, или будет убран по истечении таймаута с откатом транзакции. Вариантов — вагон.
IT>А какой должен быть таймаут? Вдруг баба Маня решила доделать работу после обеда или вообще завтра, а завтра опа, баба Маня, вся твоя работа expired.

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

IT>>>По всей видимости уже просто поздно. Если ты зашил алгоритмы расчёта больничного в БЛ на сервере, то я тебе сочувствую.
ГВ>>Странно. Если зашивать БЛ в хранимых процедурах, то это хорошо, если в в промежуточном слое — плохо, а если на клиенте, то опять хорошо. О, загадочная русская душа!

IT>Во первых про SP это твои фантазии, я такого нигде не говорил. Во-вторых, БЛ о которой идёт речь настолько часто меняется, что должна сама быть имплементирована как часть данных системы. В этом случае куда её подгрузить и где выполнить нет никакой разницы.

Ну хорошо, хорошо, ответ — ниже.

IT>>>Почему-то у нас это раньше получалось без постоянного переписыания приложений

ГВ>>Почему-то для stateful получается то же самое, что и для stateless — нужно отдеплоить новые модули, если не удаётся просто сконфигурировать старые в соответствии с новым законодательством.
IT>Мда, оригинально.

Ну, наверное, я туп до безобразия, что другого выхода не вижу.

ИМХО, если нельзя учесть очередной вираж законодательства ОДНИМ ТОЛЬКО обновлением конфигурационных данных в БД (частный случай хранения конфигурации), то надо переписать часть БЛ и передеплоить оную.

IT>>>В твоём stateful пользователь получит подтверждение что всё OK, но гарантии что это так совсем нет. Рассказы о надёжности памяти сервера — это всё ерунда. Не память так каналы связи, не связь так ещё что-нибудь. Надёжный источник только один — жёсткий диск.
ГВ>>Игорь, тема с откложенными транзакциями поднималась в контексте разговора об оптимизациях.
IT>Не твои ли слова?

IT>

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

Вот реплика, на которую я отвечал:

>> AVK>>Та же бяка в случае тяжелых и сложных алгоритмов, особенно если они распределенные, правда в этом случае хотя бы от клиента не зависим.
>> IT>С ними всегда бяка.
>> Тем не менее в стейтфул модели бяка поменьше.
TK>TK>А если это long running транзакция? Наобходимось сброса состояния на каждом шаге — для statefull это выглядит достаточно странно.

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

ГВ>>Вовсе не обязательно откладывать абсолютно все транзакции. Т.е., отклик "OK", полученный со stateful-сервера вполне себе может для данного конкретного приложения обычно означать, что получено такое же подтверждение от SQL-сервера и транзакция зафиксирована в долговременном хранилище.
IT>Обязательно не откладывать ни одной.

Обязательно обеспечить ACID (мы обсуждаем конкретно — D) на уровне системы, т.е., для её пользователей. А уж как там она обеспечивается — не их дело.

ГВ>>Собственно говоря, это пользователя совсем не касается, а касается только и исключительно разработчиков системы. Юзер должен знать, что пока он не нажал на Save ему не желательно выключать свой компьютер, а после Save он уже может выключить свою машину (пролить на неё кофе, переустановить Windows...), включить заново и снова загрузить то, чему он сделал Save. Откуда придёт появится документ — из кэша App-сервера, с диска SQL-сервера и прочее — не имеет никакого значения.
IT>Из кэша или сервера без разницы. Но ты говоришь не о кэше, а о хранилище в памяти апп-сервера, а это большая разница.

Да, извини, оговорился. Выдленный фрагмент следует читать как "из памяти промежуточных состояний App-сервера".

... << RSDN@Home 1.1.2 beta 2 >>

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

IT>>>А это уже бабе Мане решать.
ГВ>>Смешно.

Уже вижу бабу Маню с дебуггером в руках.

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

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

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

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

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

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ> Сие есть простейший выход из ситуации.
Одно непонятно, зачем в нее вообще входить?

ГВ>Я получаю отклик "OK" от App-сервера, который в данный момент (данной конфигурации и т.п.) не использует отложенных транзакций, ergo данные занесены на диск SQL-сервера. В чём промашка?
В том, что написана гора кода, для обеспечения функциональности, которая и так есть в БД.

ГВ>Ему по-любому над чем-нибудь, да надо будет "свечку держать": либо над UPS либо над винтами.

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

ГВ> На всякий случай, ещё раз повторяю: откладывание транзакций — необязательно используемая возможность.
Да зачем ее вообще вводить?

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

ГВ>> Сие есть простейший выход из ситуации.
M>Одно непонятно, зачем в нее вообще входить?

Ну не включай отложенные транзакции.

ГВ>>Я получаю отклик "OK" от App-сервера, который в данный момент (данной конфигурации и т.п.) не использует отложенных транзакций, ergo данные занесены на диск SQL-сервера. В чём промашка?
M>В том, что написана гора кода, для обеспечения функциональности, которая и так есть в БД.

Ещё раз, медленно. Отложенные транзакции являются следствием stateful-модели, используемой для реализации бизнес-логики. Обеспечением необходимой функциональности занимается App-ядро, которое вообще-то пишется совсем не ради отложенных транзакций, а ради однократной и реюзабельной реализации ряда возможностей, в том числе — объектно-ориентированного программированиябизнес-логики (см. Object-Relational Mapping, например).

ГВ>>Ему по-любому над чем-нибудь, да надо будет "свечку держать": либо над UPS либо над винтами.

M>Над винтами держать не обязательно, он может и мирроринг настроить, хоть на десять дисков, и данные сливать хоть в другую страну, в полном онлайне, совершенно стандартными средствами.

Ну-ну, попробуй не "держать свечку над винтами"...

ГВ>> На всякий случай, ещё раз повторяю: откладывание транзакций — необязательно используемая возможность.
M>Да зачем ее вообще вводить?

Причины всё те же самые: скорость исполнения и удобство программирования в ряде случаев. Всё на поверхности.

И десять раз тут уже поминалось.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>Ещё раз, медленно. Отложенные транзакции являются следствием stateful-модели, используемой для реализации бизнес-логики.
Да ну? А значит без отложенных транзакций — это уже не stateful?

ГВ>Обеспечением необходимой функциональности занимается App-ядро, которое вообще-то пишется совсем не ради отложенных транзакций, а ради однократной и реюзабельной реализации ряда возможностей, в том числе — объектно-ориентированного программированиябизнес-логики (см. Object-Relational Mapping, например).
И которое с тем же успехом может быть написано и в stateless модели. Ровно с тем же самым ORM.
С другой стороны, опять-таки можно реализовать тот же самый stateful и без отложенных транзакций.
Нафига они вообще нужны ты так и не объяснил.

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

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

ГВ>>Ещё раз, медленно. Отложенные транзакции являются следствием stateful-модели, используемой для реализации бизнес-логики.
M>Да ну? А значит без отложенных транзакций — это уже не stateful?

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

ГВ>>Обеспечением необходимой функциональности занимается App-ядро, которое вообще-то пишется совсем не ради отложенных транзакций, а ради однократной и реюзабельной реализации ряда возможностей, в том числе — объектно-ориентированного программированиябизнес-логики (см. Object-Relational Mapping, например).
M>И которое с тем же успехом может быть написано и в stateless модели. Ровно с тем же самым ORM.

Ну пиши.

Особливо — "ровно с тем же самым ORM".

M>С другой стороны, опять-таки можно реализовать тот же самый stateful и без отложенных транзакций.
M>Нафига они вообще нужны ты так и не объяснил.

Для снижения нагрузки на SQL-сервер, только и всего.

ГВ>>Причины всё те же самые: скорость исполнения и удобство программирования в ряде случаев.
M>Выигрыш в скорости если и есть, то совсем мизерный. Удобства тоже никакого, скорее привычка.

Ну, это твоё собственное ХО.

Если ты себя убедил в том, что "stateless — рулез форева", то тоже неплохо.

... << RSDN@Home 1.1.2 beta 2 >>

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

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

ГВ>Для снижения нагрузки на SQL-сервер, только и всего.

Много там не на снижаешься..
В stateful узкое место уже не сиквел, а как раз app-ядро. А ты его еще заставляешь сиквеловскую работу по durability и recovery выполнять.

ГВ>Ну, это твоё собственное ХО.

Если ты себя убедил в том, что "stateless — рулез форева", то тоже неплохо.
Да тут речь даже не о stateless vs stateful, а о том, что отложенные транзакции — это полная задница.
И если stateful без них сделать проблематично, то тем хуже для stateful.

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

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

Ну, смотря откуда посмотреть.

ГВ>>Для снижения нагрузки на SQL-сервер, только и всего.

M>Много там не на снижаешься..
M>В stateful узкое место уже не сиквел, а как раз app-ядро. А ты его еще заставляешь сиквеловскую работу по durability и recovery выполнять.

Здесь нужно добавлять "на мой взгляд", или "ИМХО".

ГВ>>Ну, это твоё собственное ХО.

Если ты себя убедил в том, что "stateless — рулез форева", то тоже неплохо.
M>Да тут речь даже не о stateless vs stateful, а о том, что отложенные транзакции — это полная задница.
M>И если stateful без них сделать проблематично, то тем хуже для stateful.

Ещё раз. Stateful вовсе не означает "отложенные транзакции", а вот отложенные транзакции — означает stateful. Т.е., не имея stateful транзакции отложить сложно, но можно. А если есть stateful-ядро, то их откладывать можно, хотя и не обязательно.

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>Не один.

Что за намёки?

IT>Да-да, простите, двое вас

неправда.. минимум — трое...

... << RSDN@Home 1.1.2 beta 2 >>

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

ГВ>>>Не один.

Что за намёки?

IT>>Да-да, простите, двое вас

H_D>неправда.. минимум — трое...

Тебя мы им не отдадим. С тобой нужно просто провести разъяснительную работу и ты одумаешься

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

IT>Тебя мы им не отдадим. С тобой нужно просто провести разъяснительную работу и ты одумаешься

да? и выкину 6 лет работы коту под хвост? фигушки

я уже 6 лет занят разработкой концепции нормального (с моей точки зрения) AppServer'а...
основной режим работы — statefull, побочным может будет stateless.... правда через то самое отверстие

... << RSDN@Home 1.1.2 beta 2 >>

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

H_D>я уже 6 лет занят разработкой концепции нормального (с моей точки зрения) AppServer'а...

Ну и как? С места сдвинулось?

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

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

H_D>>я уже 6 лет занят разработкой концепции нормального (с моей точки зрения) AppServer'а...

IT>Ну и как? С места сдвинулось?

ну... 6 макетов написано.. щаз бета пишется...

вернее — RC

... << RSDN@Home 1.1.2 beta 2 >>

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

H_D>>>я уже 6 лет занят разработкой концепции нормального (с моей точки зрения) AppServer'а...

IT>>Ну и как? С места сдвинулось?

H_D>ну... 6 макетов написано.. щаз бета пишется...

вернее — RC

Т.е. в год по макету. Здорово. Начинал наверное ещё когда DCOM только выходил из дверей Microsoft Research, а заканчиваешь, когда уже на смену Remoting'у идёт Indigo.
Классно вам стейтфульщикам живётся

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

IT>Т.е. в год по макету. Здорово. Начинал наверное ещё когда DCOM только выходил из дверей Microsoft Research, а заканчиваешь, когда уже на смену Remoting'у идёт Indigo.
IT>Классно вам стейтфульщикам живётся

DCOM меня и не интересовал... а сроки... это же до недавнего времени так — хобби было...

... << RSDN@Home 1.1.2 beta 2 >>

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

хъ

IT>Т.е. в год по макету. Здорово. Начинал наверное ещё когда DCOM только выходил из дверей Microsoft Research, а заканчиваешь, когда уже на смену Remoting'у идёт Indigo.
IT>Классно вам стейтфульщикам живётся

DCOM вышел восемь лет назад. Когда Хакер начал работать, он уже победным маршем шел по планете.

Я думаю, Хакер закончит, когда страрый Дон придумает чем заменить Индигу.

... << RSDN@Home 1.1.0 stable >>

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

AS>Я думаю, Хакер закончит, когда страрый Дон придумает чем заменить Индигу.

Хорошего же ты обо мне мнения

... << RSDN@Home 1.1.2 beta 2 >>

IT>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё

А можно мне хоть намекнуть как при помощи:
1. .NET в которой нет идеологии Dynamic курсоров
2. Stateless

Сообразить скажем систему обеспечивающую торговлю скажем какимето акциями ( хочу real time ).
hint 1: Изменения котировок должны приходить как можно быстрее
hint 2: Pooling не предлогать

... << RSDN@Home 1.1 beta 1 >>

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

Tom>А можно мне хоть намекнуть как при помощи:
Tom>1. .NET в которой нет идеологии Dynamic курсоров
Tom>2. Stateless

Tom>Сообразить скажем систему обеспечивающую торговлю скажем какимето акциями ( хочу real time ).
Tom>hint 1: Изменения котировок должны приходить как можно быстрее
Tom>hint 2: Pooling не предлогать

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

IT>В общем ход твоих мыслей я уже давно потерял, но мимо этого пройти не могу, религия не позволяет

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

А может ты путаешь stateless и persistent connection less?

Слово то простое. stateless и говорит оно что state less а не state у нас в базе данных и мы тут его ручками круто эмулируем

... << RSDN@Home 1.1 beta 1 >>

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

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

TK>>>А сервер у тебя тоже будет 100 000 клиентов уведомлять и ссылки на них держать? А если один отвалился (не на долго, совсем на чуть-чуть)? А если клиент за firewall?
TK>>>Я-то поставлю SQL Server Notification Services и думать забуду о количестве пользователей. А что будешь делать ты? Какой велосипед придется создать на этот раз?
H_D>>Так, я не понял... если мы говорим о стейтлесс — какой SQL Server Notification Services?? а если мы храним контекст пользователя — это не стейтлесс..

TK>Нет никакого контекста пользователя. Клиент просто вызывает веб метод, где указывает свой endpoint и в каких уведомлениях он заинтересован. Никакого глобального состояния в памяти держать не надо — это примитивная операция которая сравни подписке на любую рассылку.

В данном члучае состояние — это состояние подписки. Т.е:
1. Подписан/не подписан
2. на что именно подписан

... << RSDN@Home 1.1 beta 1 >>

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

ZEN>Смотрю я на эту ветку и думаю, когда же, наконец, начнут обсуждение реализации stateful-модели в J2EE/EJB-сервере(рах) приложений. Видимо, не дождусь... ;(

ZEN>MS напирает на stateless-модель из-за сложности реализации другого в COM+ (механизм моникёров требует прямоты рук) — это понятно.
гм. Да вроде как нааборот. Все сложности в COM+ начинаются из за stateless. JIT там, а из за него Synchronization... А Моникеры тут не причём.

ZEN>И здесь, видимо, собрались практики и знатоки именно технологий от MS (BizTalk, например, упоминается очень часто), а альтернативы нету.
XGen

ZEN>Что скажете? Интересно было бы послушать альтернативщиков платформы MS, прежде всего из стана Java.
Нету у нас таких

Кроме AVK да и он думаю давно уже на Явист.

... << RSDN@Home 1.1 beta 1 >>

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

Ой. Я как то не вкурсе. Спасибо что просветил меня не знающего

Что теперь модно?

... << RSDN@Home 1.1 beta 1 >>

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

Tom>А может ты путаешь stateless и persistent connection less?

Это термин совсем из другой оперы, к нашему разговору отношения не имеет

Tom>Слово то простое. stateless и говорит оно что state less а не state у нас в базе данных и мы тут его ручками круто эмулируем

Только не надо сочинять собственную интерпретацию устоявшейся терминологии. Stateless — это stateless, т.е. без состояния. А после 'state less' напрашивается как минимум 'than'

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

Tom>Ой. Я как то не вкурсе. Спасибо что просветил меня не знающего

Да я как бы не тебе отвечал

... << RSDN@Home 1.1.2 beta 2 >>

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

Гы

У нас это реализовали именно на основе OLE DB и Dynamic курсоров, а вот Ты решения на основе stateless так и не предложил.

... << RSDN@Home 1.1 beta 1 >>

AVK>Да я как бы не тебе отвечал

Ну ничего. И меня просветишь. Ты же разбираешься в COM+ так и просвети меня.

... << RSDN@Home 1.1 beta 1 >>

Tom>>А может ты путаешь stateless и persistent connection less?

IT>Это термин совсем из другой оперы, к нашему разговору отношения не имеет

Давай так: stateless — это когда состояния НЕТ, а не когда состояние есть но хранится не понятно где

Tom>>Слово то простое. stateless и говорит оно что state less а не state у нас в базе данных и мы тут его ручками круто эмулируем

IT>Только не надо сочинять собственную интерпретацию устоявшейся терминологии. Stateless — это stateless, т.е. без состояния. А после 'state less' напрашивается как минимум 'than'

ты это. не отмазывайся

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

... << RSDN@Home 1.1 beta 1 >>

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

AVK>>Да я как бы не тебе отвечал

Tom>Ну ничего. И меня просветишь. Ты же разбираешься в COM+ так и просвети меня.

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

... << RSDN@Home 1.1.2 beta 2 >>

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

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

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

... << RSDN@Home 1.1 beta 1 >>

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

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

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

... << RSDN@Home 1.1.2 beta 2 >>

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

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

... << RSDN@Home 1.1 beta 1 >>

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

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

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

... << RSDN@Home 1.1.2 beta 2 >>

Здравствуйте, 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

Кто то ж за него грудью стоит

... << RSDN@Home 1.1 beta 1 >>

Здравствуйте, 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 (и они, ИМХО, совершенно правы), а другие давят на то, что это приведёт к снижению производительности и к неудобству программирования (ИМХО, тоже совсем небезосновательно). Ну а дальше всё как полагается в порядочном споре — сарказм, язвительности, тень на всех плетнях и т.п.

... << RSDN@Home 1.1.2 beta 2 >>

Здравствуйте, 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 говоришь?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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. Пример из жизни. Загружаешь ты, например, накладную. Вместе с ней поднимается и товары. Товаров в базе данных мильёны. Грузить их все в кешь не имеет смысла. А может и имеет для каких-то случаев

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

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, но и убедить всех, что это единственно правильное решение. Это не так. Уверен, что твою задачу можно было бы спокойно решить малой кровью без строительства завода для производства одного гвоздя.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, 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>

Маловероятно. Я просто имел в виду режим "сквозной работы" 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 именно из-за побочных эффектов в случае неккоректного завершения клиентского приложения, ненадежных блокировок документов и т.д.

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

От:	Tom	http://www.RSDN.ru
Дата:	04.12.03 13:50
Оценка:	2 (1)

	От:	Ведмедь
	Дата:	04.12.03 13:54
	Оценка:	6 (1)

От:	Mika Soukhov	Stock#
Дата:	04.12.03 14:02
Оценка:	+1

От:	LaFlour	blog: http://spaces.live.com/laflour
Дата:	04.12.03 14:03
Оценка:	6 (1)

	От:	outsourcer
	Дата:	04.12.03 14:08
	Оценка:	6 (1)

От:	IT	linq2db.com
Дата:	04.12.03 14:46
Оценка:	6 (1) +5

От:	Alexey Shirshov	http://wise-orm.com
Дата:	05.12.03 07:27
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	06.12.03 15:45
Оценка:

	От:	Igor Trofimov
	Дата:	07.12.03 08:59
	Оценка:	10 (1) +2

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	07.12.03 10:20
Оценка:	10 (1) +2

От:	TK	кывт.рф
Дата:	07.12.03 12:15
Оценка:	75 (3) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	08.12.03 10:32
Оценка:	36 (5) +1

От:	Merle	http://rsdn.ru
Дата:	08.12.03 13:02
Оценка:	+1

	От:	Hacker_Delphi
	Дата:	08.12.03 16:51
	Оценка:	33 (2)