Into my EWF_APP[EWF_APP_EXECUTION] the EWF_APP_EXECUTION inherits from WSF_FILTERED_ROUTED_EXECUTION defining setup_router.
To be able to access informations globally by thread (as far as I understand the implementation also SCOOP region in this case), I have defined a {MY_APPLICATION_ENVIRONMENT}.app_instance which is once (by default, thread). This app_instance as a handlers: LINKED_LIST[MY_HANDLER] which is also a once and by that mecanism I'm able to access a handler instance to get some polymorphic item_prototype I reuse into my business.
I also do the same mecanism with db_services: LINKED_LIST[DB_SERVICE[DB_ENTITY]] to be able to get a DB_SERVICE from its DB_ENTITY name.
With the above mecanism so far, only into the {EWF_APP_EXECUTION}.setup_router I create the db services, handlers, and extend the thread app_instance.
I figured out that the setup_router being called on each request, my handlers and db_services collections into {MY_APPLICATION_ENVIRONMENT}.app_instance grows up infinitly causing memory leaks.
What would be the best strategy on this case? is it doable on this context as the router seems to be recreated on every request to setup the router with the existing handlers?
Hoping I made me clear enough...
The EiffelWeb design is based on WSF_EXECUTION with a given WSF_REQUEST and WSF_RESPONSE. The interface are very limited, so any kind of framework extension can be built on top of them. The class WSF_ROUTED_EXECUTION is based on that interface and "add" the routing facility. Check the code, and you will understand how this is implemented. See WSF_ROUTED_EXECUTION.initialize and then WSF_ROUTED_EXECUTION.execute. The FILTERED_ROUTED_EXECUTION is adding the notion of filters, but this is just an extension, so the "routed" design reminds the same.