Я разрабатываю приложение прямо сейчас, которое создает и хранит соединение с локальным сервером XMPP в Области действия приложения. Методы соединения хранятся в cfc, который удостоверяется Приложение. XMPPConnection соединен и авторизовал каждый раз, когда он используется и использует соединение, чтобы отправить прямые трансляции пользователям. Насколько я могу сказать, это хорошо работает. НО это не было протестировано ни под каким видом напряжения.
Мой вопрос: это настроит проблемы причины позже? Я только спрашиваю, потому что я не могу найти доказательство других людей, использующих переменные Приложения таким образом. Если бы я не использовал railo, то я использовал бы шлюз события CF вместо этого для выполнения той же задачи.
Размер сам по себе не является проблемой. Если бы вы инициализировали по одному объекту на запрос, вы бы сожгли гораздо больше памяти. Проблема в доступе.
Если у вас большое количество запросов, конкурирующих за один и тот же объект, вам нужно измерить время доступа к этому объекту по сравнению с инстанцированием. Имейте в виду, что для объектов данных их может читать более одного потока. Однако, насколько я понимаю, когда вызывается функция объекта, она блокирует этот объект для других потоков до тех пор, пока функция не вернется.
Кроме того, если объект поддерживает состояние, вам нужно подумать о том, что делать, когда несколько потоков получают/устанавливают эти данные. Не возникнут ли в итоге условия гонки?
Вы можете рассмотреть возможность работы с этим объектом в области видимости сессии, чтобы он инстанцировался только для каждого пользователя (который, скорее всего, будет делать только один или два одновременных запроса).
Конечно, вы можете использовать область приложения для хранения этих компонентов, если они используются всеми пользователями в разных частях приложения. Теперь возможны следующие проблемы:
Во-первых, есть способы рассчитать размер компонента в памяти. В последнее время на эту тему было много сообщений, так что найти их будет несложно. Если у вас нет сохраненной большой структуры или запроса, я думаю, вы здесь в порядке.
Во-вторых, опять же, если вы не заполняете этот cfc каким-либо большим запросом из БД или не выполняете медленный синтаксический анализ, вы тоже в порядке.
В-третьих, обратите внимание на возможные ситуации, когда большее количество пользователей меняют состояния этих компонентов. В таком случае используйте cflock для каждой настройки компонентов state.