Блог

В моем EWF_APP[EWF_APP_EXECUTION] EWF_APP_EXECUTION случае наследуется от WSF_FILTERED_ROUTED_EXECUTION определения setup_router .

Чтобы иметь возможность глобального доступа к информации по потоку (насколько я понимаю, в данном случае реализация также охватывает область), я определил a {MY_APPLICATION_ENVIRONMENT}.app_instance , который является once (по умолчанию thread). app_instance Это handlers: LINKED_LIST[MY_HANDLER] также один раз, и благодаря этому механизму я могу получить доступ к экземпляру обработчика, чтобы получить некоторый полиморфный item_prototype, который я повторно использую в своем бизнесе.

Я также выполняю тот же механизм, db_services: LINKED_LIST[DB_SERVICE[DB_ENTITY]] чтобы иметь возможность получать a DB_SERVICE из его DB_ENTITY имени.

С помощью вышеупомянутого механизма до сих пор только в {EWF_APP_EXECUTION}.setup_router I я создаю службы db, обработчики и расширяю поток app_instance .

Я выяснил, что при setup_router вызове каждого запроса мои обработчики и коллекции {MY_APPLICATION_ENVIRONMENT}.app_instance db_services бесконечно увеличиваются, вызывая утечки памяти.

Какова была бы лучшая стратегия в этом случае? выполнимо ли это в этом контексте, поскольку router , похоже, он воссоздается при каждом запросе на настройку маршрутизатора с существующими обработчиками?

Надеюсь, я достаточно ясно объяснил…

Дизайн EiffelWeb основан на WSF_EXECUTION с заданными WSF_REQUEST и WSF_RESPONSE. Интерфейсы очень ограничены, поэтому поверх них можно построить любое расширение фреймворка. Класс WSF_ROUTED_EXECUTION основан на этом интерфейсе и «добавляет» средство маршрутизации. Проверьте код, и вы поймете, как это реализовано. См. WSF_ROUTED_EXECUTION.initialize, а затем WSF_ROUTED_EXECUTION.execute . FILTERED_ROUTED_EXECUTION добавляет понятие фильтров, но это всего лишь расширение, поэтому «маршрутизируемый» дизайн напоминает то же самое.