Здравствуйте, Alexey Shirshov, Вы писали:
AS>Не согласен. Или поясни более подробно, что ты имел в виду под процедурной функциональностью.
Ровно то, что диктует серверу, что и когда ему делать. Триггер — это пример процедурной функциональности. Оригинальный SQL полностью декларативен.

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

AS>Зачмечательно. Только вот когда ты будешь делать кластер, ты поимеешь серьезные проблемы от синхронизации апп-серверов.
Это только в том случае, если апп-сервер стейтфул А я этого слова пока не сказал.
AS>Вот поэтому и плохи триггеры (кроме того, что они просто замедляют работу сервера).
Да, именно это я и имею в виду. Триггеры и есть процедурное средство поддержки целостности.
AS>Я за SQL-сервер как средство долговременного хранения бизнес-информации и как средство эффективной работы с ними. Пусть хоть 1000 запросов в секунду придется ему выдерживать.
AS>Городить огород из собственных наработок в таком уском месте — потеря времени и сил. Путь даже в некоторых случаях это может и привести к росту производительности.
Угу.

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

S>А вот обо всем этом мы поговорим 15го, ибо я ЕДУ В МОСКВУ!!!!

Ну если ты, в отличие от предыдущих людей и разов повываешь не только в выходные то есть шанс что поговорим

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

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

Здравствуйте, AndrewVK, Вы писали:
AVK>Ну если ты, в отличие от предыдущих людей и разов повываешь не только в выходные то есть шанс что поговорим
Ну, я буду 15го на встрече offline community. Командировку уже выбил, послезавтра буду билеты заказывать...

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

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

S>Дело не в доверии. Дело в ACID. Отложенные записи — прямая дорога в ад.

Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом. Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.

S>Мы не имеем права отказываться от committed транзакций. Сколько бы уровней ни было, OLTP система обязана убедиться в том, что durability достигнута прежде, чем отрапортовать об окончании транзакции. Точка. В некоторых особо редких случаях это не так важно, но это уже не OLTP система, а что-то другое.

Какая разница, есть для этого термин или нет? Единственное ограничение — не знаешь, что именно писать в рекламных проспектах.

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

M>Если у тебя действие атомарное, то ты по любому транзакцию начал, а потом зафиксировал, и все через БД.

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

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

M>>Если у тебя действие атомарное, то ты по любому транзакцию начал, а потом зафиксировал, и все через БД.

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

Что, если мы пишем метод который в рамках одной транзакции пишет => читает => обновляет то это уже не stateless метод?

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

ГВ>Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом. Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
Ну это скорее не стериотип, а осознание того факта, что организовывать полноценный ACID собственными силами — развлекуха для экстремалов. Я затрудняюсь себе представить в каких условиях это было бы выгодно, особенно при наличии готового универсального механизма.

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


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

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом.
Именно об этом я и говорю. Просто отложенная запись и durability — вещи плохо совместимые. MS SQL ухитряtтся совмещать эти два факта благодаря тому, что откладывает запись самих данных. Журнал пишется синхронно. Подтверждение коммита гарантирует сброс на носитель трейлера журнала транзакций.
Фактически речь идет о том, что если ты пообещал Durability, тебе необходимо гарантировать, что отложенные записи не станут потерянными записями даже при application fault.
ГВ>Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
Да нет конечно, вот только ACID уже встроена в СУБД, и это далось им достаточно большой кровью. У меня потеют ладони, когда я думаю о самопальной реализации ACID. Если мы получим полноценное универсальное решение для ACID за пределами RDBMS, нас станут носить на руках и цитировать в учебниках
ГВ>Какая разница, есть для этого термин или нет? Единственное ограничение — не знаешь, что именно писать в рекламных проспектах.
Ок, главное — два билета на одно место не продать.

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

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 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

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

> Да, не всё конечно, просто, но тут ты всё-таки несколько утрируешь. ACID должен соблюдаться на уровне системы в целом. Это просто один из многих стереотипов, что реализация ACID — прерогатива только СУБД.
>

Можно ссылку на app сервер реализующий поддержку ACID для объектов в памяти?

Hello, "Sinclair"
>
> TK>Да, их еще несколько может быть. Как насчет кинуть сюда код std::map который будет для быстрого поиска данных не только по целочисленному PK, но и по имени того-же клиента (т.е. ключа два)? На всякий случай еще небольшая опция через некоторое время появится и еще один индекс. Все это храним в app сервере?
> Тут ты что-то путаешь. Сколько индексов — столько мапов. Они никак друг другу не мешают. Главное — хранить в метаданных список всех мапов, которые надо трогать при изменении свойств объекта (для синхронизации индексов).
> Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...

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

Здравствуйте, 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. Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
   
2. Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.
   
3. Предположение 1. Если режим == стейтлесс и используются Serializable объекты на стороне клиента, значит из (1) и (2) вся работа, связаная с бизнес логикой выполняется через вызовы Serviced объекта (т.е. по сути вызов процедур сервера).
   
4. Следствие 1. из (3) получаем, что методы объекту, который отдается клиенту как бы и не нужны (все равно он все должен на сервере делать) единственное, что нужно объекту, который отдается клиенту — методы для некоего упрощения отображения,
   типовых операций, которые можно сделать и в виде внешних классов на клиенте.
   То есть в случае, если верно (3) — стейтлесс получается не ООП, а процедурным программированием, что откатывает нас назад в развитии программирования, так как почти ничем не отличается от RDBMS
   
5. Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.
   
6. Предположение 2. Пусть режим стейтлесс и используется не Serializable объекты, а MBR.
   
7. Утверждение 3. из (6) мы получаем ровно две стратегии для соблюдения атомарности изменений:
   
   • Стратегия № 1 ( известная как pessimistic locking + Repeatable Read): Мы должны блокировать объект, к которому кто-то получил доступ. Иначе, при начале изменений этим кем-то, все, кто уже получили тот же объект на чтение, будут иметь неактуальные (частичные) данные. В данной стратегии развития, мы получаем, что один человек, взявший в работу объект, не дает работать всем, кому этот объект нужен зачем-либо, пусть даже для join'ов.
     
   • стратегия №2 (на самом деле — их три, близких по смыслу, известных как Versioning, Read Commited, optimistic locking ) либо делать "скрытое копирование" (Versioning, Read Commited) с блокировкой на изменение объекта (Read Commited) или же просто блокировать объект с "отстрелом всех активных "читателей" (optimistic locking) при начале изменений объекта либо при начале транзакции.
   
   
8. Следствие 2. из (7). получаем, что если нам нужна интерактивная система — мы должны использовать изменение через копирование, т.е. Versioning или Read Commited. Причем, optimistic locking нам не совсем подходит, так как "морозит" работу всех остальных клиентов, которые уже работали с объектами, которые кто-то меняет.
   
9. Следствие 3. Так как из (6) все объекты — MBR (или, тем более, CBO), значит состояние хранится на сервере, то есть сервер "в курсе" контекста ывполнения тех или иных операций над объектами, так как все изменения требуют копирования объектов, с "привязкой" этих копий к конкретному человеку.
   
10. Вывод 2. Из (7) и (9), через (8) мы получаем, что создание интерактивных систем со всегда актуальными данными на базе стейтлесс с использованием MBR невозможно.
    
11. Предположение 3. Вернемся к Предположению 1 (1). Итак, Serializable и мы позволяем клиенту делать с объектом(-ами) все, что угодно, а при пересылке его (их) на сервер проверяем валидность действий и либо принимаем транзакцию, либо отменяем.
    
12. Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.
    
13. Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели.
    
14. Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс.

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

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

1. мы взяли из "неизменного" источника товар
   
2. ввели количество
   
3. возможно исправили цену
   
4. Послали запрос и или получили 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 по Москве, так что ежели чего пропустил — не обессудьте

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 по одной простой причине: в остальных случаях мы получаем, на самом деле, только набор структур с методами работы с ними.
>

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

Ну а обсуждение НЕВОЗМОЖНОЙ леммы продолжим в следующей серии

Здравствуйте, 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>В общем, не на том акцентируете внимание, товарищи.
Угу. Тут попробуй сказать что нить. Так сразу или 'стэйтфульщик' или ещё чего