Stateful Application.cfc

dev
1

So far the Application.cfc is stateless, means every request does create a new instance of the Application.cfc. What do you think about a setting that allows to make it stateful, so Lucee will only create a single instance for the live time of the Application scope.

That would allow to have a internal state of the Application.cfc, this would help a lot with performance, downside would be that it is not that easy to have a different environment for single requests.

2

Do you have numbers to back this up? I’m aware the Application.cfc instance gets created every request, etc, etc, but I’m curious because in actual performance tests I’ve done, I’ve seen the disk IO check to see if the Application.cfc exits, but I can’t say I’ve seen the code that actually loads the Application.cfc and its settings appear as a “slow” part of any request when I’m profiling performance.

As for the feature, I’m not against it. The irony is most CF devs actually assume CF works this way already. Many legacy CF apps make heavy use of custom settings per request, but many don’t and this setting wpuld be perfect for them. It could just be an annotation on the CFC itself like

Application.cfc

component singleton {
}
3

I often dynamically set the application name (in the constructor) to be based on the hostname / webroot path, how would would this be affected?

With single context mode in Lucee 6, using unique application names becomes more important than before

4

It won’t no longer work IF you expect different requests to the same application to have a different hostname. The webroot obviously won’t change since that’s tied to where the Application.cfc actually lives. But if you have 25 domain names and 25 application scopes to match inside a single code base (web root), that would not be possible with the proposed singleton idea.

I think you’re conflating applications with web/server contexts. These are different things. A single context can have a dozen CF applications simply by having a dozen folders, each with an Application.cfc with a unique name in them.

5

but when running the same named application in different web contexts, they completely separated?

6

No, of course not, this is ATM just an idea. But i know the overhead we have to do in order to support a separate Application.cfc instances for every single request, specially when you have a “onSessionEnd” or “onApplicationEnd”.

I actually did enable this once in a snapshot years ago in a very simple way, with the “dev” update provider we had back then. I was curious about the feedback on this change, users did report problems with that version right away :wink:

7

yes of course, you have completely separated.

IF you run Lucee in single context mode and you have an application.cfc that looks like this

component {
   this.name=cgi.server_name;
}

you better do not use that FEATURE, but of course you can also do something like this

component single=true {
   this.name="main";
   function onApplicationStart() {
      application.data[cgi.server_name]={};
   }
}

But the idea of this feature is not to limit you, it is about having option. i would say IF i already use the Application.cfc in that way, what many applications do, why not benefit from this and give the application.cfc a useful lifecycle, that gives you new options.
I see a lot of application.cfc that have 100s of lines like this

this.sessionmanagement=true;
this.sessioncluster=true;
this.sessiontimeout=...;

Today we execute this lines with every request and based on this data we create a ApplicationContext instance every time, all that is a big overhead that is not necessary for many applications.

1 Like