Здравствуйте, 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.

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

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

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

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


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

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

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

Как?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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) и свои особенности. Понятно что это уже сервер приложений в чистом виде.

Здравствуйте, 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 системам.

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

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

хъ

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

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

хъ

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

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

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

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

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

хъ

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

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

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

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

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

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

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

Про разделение на слои пока речь не идет.

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

Здравствуйте, 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 транзакции?
Я о том и говорю что не стоит себя ограничивать рамками одной модели. Подобная схема с одной стороны ведет себя очень похоже на стейтлес, с другой в бизнес-коде это выглядит как стейтфул, поскольку надобность бизнес кода в залазивании в чужую транзакцию сомнительна.

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

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

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

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

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

M>То есть? Транзакция рано или поздно должна сказать commit и после этого она не имеет права откатиться.

А после этого прежде чем что то поменять нужно начать новую.

Здравствуйте, 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>С хранением состояния никто не спорит. основной вопрос — как к этому подходить.

Ну это уже совсем другой вопрос.

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

AVK>А это уже из другой области, из области индиго. У индиго свой хост (ServerEnvironment) и свои особенности. Понятно что это уже сервер приложений в чистом виде.
А вот обо всем этом мы поговорим 15го, ибо я ЕДУ В МОСКВУ!!!!

Здравствуйте, 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-системы. Это вообще вопрос отдельный.