Антон Аксёнов,
Вы написали много слов, но большинство из них проходят мимо моего сознания, видимо в следствии ограниченного кругозора. ("салатный код из колбэков", "архитектура монстра-молотилки" и т.п.) Но я не об этом, знание некоторых принципов позволяет не заботиться о запоминании множества фактов.
Ой ладно вам, я уверен - вы скромничаете. Уж что такое callback-hell вы должны знать. И если программировать под вэб, в рамках "ответить надо быстро иначе клиент отвалится", то понимание должно быть что долгую обработку с интерактивом надо пилить на несколько этапов, если между этапами подразумевается некий интерактив с пользователем. А колбэк - это кусок алгоритма срабатывающий после того как та сторона (пользователь) ответит, и обрабатывает ответ, использует его в дальнейших рассчётах.
Монстр-молотилка - это процесс (в широком понимании) который обрабатывает очередь поступивших запросов.
Я за то что бы небыло запросов, а были свои джобы на каждое соединение которые бы обрабатывали персонально каждый коннект и ЖДАЛИ бы его при необходимости интерактива. Таким образом не надо будет пилить алгоритмы на куски.
Не бог весь какая терминология, больше аналогий (не спорю, не совсем удачных, скорее экспрессивных), но дело ваше, можете не напрягаться, читая этот сумбур. Пишу не только для вас, но попробую больше про принципы, ок.
Очень просто - информация, необходимая алгоритму, располагается в оперативной памяти и занимает некоторый ее объем. Вам не все равно, в общем кэше она или в локальной среде процесса ? Если она в локальной среде, процесс становится большим и неповоротливым. Если среди этих данных есть то, что следует сохранить, получаем накладные расходы на сохранение о последующее восстановление. Таким образом, ИМХО, в локальных переменных стоит держать только то, что не страшно потерять в любой момент.
Насчет использования потоков есть здравое зерно, тут я не готов спорить.
Я же написал, мы с вами разное подразумеваем под временными данными. Вы, в силу того что привыкли к своей архитектуре распиленных бизнес-алгоритмов, считаете частью сессии то что, по сути, можно было бы к чертям потерять. Например, текущая итерация цикла прерванного для ожидания интерактива. Я так, абстрактно. Потому что у вас часть цикла в одной процедуре, а часть во второй, которая будет вызвана после ответа пользователя. И вот что бы вторая процедура продолжила нормально работу - вы храните состояние первой в сессии, ибо бедный (о чём все мои посты выше) инструментарий заставляет вас высвобождать драгоценные оплаченные деньгами джобы для обработки следующих запросов из очереди. С таким подходом у нас вообще нет выбора где хранить, если говорить только в рамках подхода обработчик очереди запросов. Где ж еще, если надо быстрее кончить и освободить джоб для следующего запроса? Какая разница, ну хотите пишите:
for ^sessions(ID,"x")=1:1:9000 s ^sessions(ID,"y")=^sessions(ID,"y")+1
Если чувство прекрасного вас обделило, хотите пишите поднятие/сохранение промежуточных данных в конце запроса.
О чём спор если по факту выбора-то нет?
А могла бы быть одна единая процедура, в которой в середине что-то спросили бы у пользователя и после получения ответа сразу бы продолжили работу, а всё состояние бизнес-алгоритма как жило в локалях так бы там и осталось.
>Таким образом, ИМХО, в локальных переменных стоит держать только то, что не страшно потерять в любой момент.
Ну тут невозможно и не зачем спорить. Это не ИМХО а прописная истина.
Вот только разрезанные интерактивом бизнес-алгоритмы в подходе "меня спросили - я ответил" вынуждены хранить в глобалях то что можно было бы потерять не парясь.
Но в принципе, абстрагируясь от сессий и всего о чём мы говорим, странная постановка вопроса про кэш. Как это какая разница, ведь одно дело держать в оперативке джоба, на кончиках пальцев, а другое дело - в расшаренном кэше, где помимо хранения и доставания данных будет еще код блокировки из-за того что оно расшарено между джобами? Это же лишний оверхед пока я работаю с моими данными. Моими интимными, больше никому не нужными данными одного конкретного соединения, возвращаясь к нашим баранам.
Это вы ловко ввернули, "при правильной настройке", а если неправильная? Тот подход за который я топлю если и требует отдельной настройки кэша сессионных данных, то этот процесс будет прогнозируем. Т.е. можно заранее прикинуть что вот столько юзеров и столько ТАКИХ-ТО данных, т.е. мы знаем что в нашем кэше сесси сиддят только данные сессии. А с подходом единого джоба-молотилки нам приходится держать в голове тот факт что в любой момент может появится интерактив внутри одного из бизнесс-процесса который заставит выгружать в этот кэш кучу данных по локальному состоянию этого алгоритма, т.к. он будет "разрублен" этим интерактивом. И вы такое не предусмотрите в жисть.
Если она в локальной среде, процесс становится большим и неповоротливым.
Я к тому что при подходе job=коннект_до_его_смерти программист волен решать и прикидывать - что лучше хранить в глобалях, т.к. оно скорее всего будет большим и неповоротливым если будет сидеть в оперативке, а что держать "горячим" в локалях. А при подходе который я критикую выбора-то и нет, повторюсь.
И еще раз, отскакивая в сторону, и немного мечтая, а неплохо было бы для джоба иметь некое хранилище для временных данных прошитое в стандарт. Что бы что-то крупное хранить на диске а не в оперативке, но без транзакций и шаринга, это должно быть видно только джобу. Вроде в cashe такое есть, специальная глобаль или что-то такое. Вот это точно в стандарт надо тащить. Это хорошая штука для тех данный сессии которые потенциально могут пухнуть.
