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

Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.

Хана твоему ООП. Сегодня рулят схемы и контракты

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. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.

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

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>Зато теперь он у меня показывает исключительно в правильном направлении, чего и Вашему желаю

Ну вобщем — да. Мы же и не север ищем.

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

IT>>Зато теперь он у меня показывает исключительно в правильном направлении, чего и Вашему желаю

ГВ>Ну вобщем — да. Мы же и не север ищем.

Простите, а что я сказал смешного?

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

IT>>>Ты в своём доказательстве забыл одну простую вещь. Для реализации подобного механизма в stateful необходимо как минимум поддерживать версию объекта, которая является частью состояния. Но ведь в stateless состояние не куда не девается, просто оно в другом месте.
ГВ>>Уффф... ну наконец-то...

IT>А разве кто-то из апологетов stateless когда-то это отрицал? Обратное утверждают и пытаются это доказать как раз сторонники stateful.
На самом деле из-за терминологии ещё некоторая путаница появляется. Суть в том, что не хочется по любому поводу привязываться к SQL-серверу, только и всего. Неудобно по ряду причин сие есть с точки зрения некоторых, к которым себя и причисляю.

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

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

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

ГВ>>Во время, отведённое мне на разработку чего? А оптимизация... Не так страшен чёрт, как...

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

А... это, в разработку системы вполне может быть включена разработка соответствующих stateful-сервисов.

IT>Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.

Ещё одно обобщение... а, ладно. Достался я уже.

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

ГВ>>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?

Вернусь к этому моему ответу. Я здесь несколько поспешно подумал, что речь только о пользователе. Просто в случае App-сервера клиентом является бизнес-код.

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

IT>>>Не забудь так же обновить все мапы, которых коснётся уменьшение зарплаты Петрову за прогулы.
ГВ>>Если нужно будет — то почему и не обновить? Кстати, ещё один вопрос: как соотносится время выполнения std::map::insert() со временем INSERT INTO?
IT>А при чём тут это. Тебе второй insert тоже делать надо, а вот мне первый совсем не обязательно

Ну... зато мне JOIN делать не обязательно.

IT>>>И когда будешь обновлять мапы не забудь залочить свой app-сервер во избежании undefined behaviour.
ГВ>>Э-э-э... знаешь ли... мапы тоже могут быть версионными.
IT>Ах у вас ещё и мапы версионные. Ну тогда гуд лак

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

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

Если не привязываться к SQL серверу, то путь только один — изобрести свой

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

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

IT>>>Зато теперь он у меня показывает исключительно в правильном направлении, чего и Вашему желаю

ГВ>>Ну вобщем — да. Мы же и не север ищем.

IT>Простите, а что я сказал смешного?

Меня просто всегда такие аллегории забавляют.

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

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

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

IT>Если не привязываться к SQL серверу, то путь только один — изобрести свой

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