Just seen this one too: Lucee 6.2 REST API Isolation from Application.cfc Variables/Methods
Is it a related issue perhaps?
I just spotted something else:
// this checks if a cookie is created, for bots this will return false and use the low session timeout
this.sessionTimeout = createTimeSpan(0, 0, 0, 2);
if (structKeyExists(cookie, "cfid") || structKeyExists(cookie, "jsessionid")) {
this.sessionTimeout = createTimeSpan(0, 0, 30, 0);
}
Here the application starts, in every case, with a session timeout of 2 seconds. This might have consequences before execution encounters the if-condition. Then again, there might be no consequences.
To be on the safe side, I would use instead:
if (structKeyExists(cookie, "cfid") || structKeyExists(cookie, "jsessionid")) {
this.sessionTimeout = createTimeSpan(0, 0, 30, 0);
} else {
this.sessionTimeout = createTimeSpan(0, 0, 0, 2);
}
that’s only metadata being set in the constructor…
accessing the session or application scope in the cfc constructor does nothing
the session will only be created on demand once you reference the session scope
Don’t know, if this helps, but I always thoght, from CFML history, that application scope would also share variables across different code basis, when you use the same this.name value and whenever you share the same engine instance. But I can’t tell that for sure, cause this is a long lasted experience I had even before Railo. What I can tell is, that I’m running the very same code with lots of identical application variable keynames across various domain/host names running in single-mode. I’m not impacted by this issue (if it is even considered as a bug), may be because I use the server name to generate the value for the application name Applicarion.cfc: this.name = cgi.server_name & "_buildVersionx.y.z"; for the reason I’ve described.
The application name defines the instance of the application scope. The application scope is specifc to each application name.
This can easily become a problem on the same server / engine instance if the application name is the same across different websites .
I would suggest if someone is on a shared instance, to build upon what you suggest, make it far more unique with:
this.name = cgi.server_name & “buildVersionx.y.z” & createUUID();
wouldn’t cgi.http_host be better than cgi.server_name?
2 Likes
More than likely, more useful. 
Yes @Zackster … I think this is in fact what I’'ve set up. @Terry_Whitney UUID is something I’ll also add. Great tip! I’ve also seen/used a hash(GetCurrentTemplatePath()) or similar, but it might not work when using the very same shared code base location for a bunch of domains. createUUID() is of course better.
1 Like
err, noooo, don’t use createUUID()! each request will get a different application name
1 Like
Isnt that what the onApplicationStart component is for?
how does it know which application it’s starting? easy enough to prove me wrong, try it out!
1 Like
I am not doubting you.
In a shared host enviroment, why would you have the same Application.cfc for two applications, unless you implicitly wanted each application to know about the other, in which isnt this moot?
Say you have 2 or 100 sites for different customers pointing to the same webroot, which load their configuration based on hostname?
Maybe I need more coffee, but
in your use case, are all the websites part of the same application? Or different segmented applications running on the same server instance?
I guess I am missing why you wouldnt want data segmentation from application-1 to application-2
#In the Application.CFC
#lets see what we are looking for
this.name = reReplace(cgi.HTTP_HOST, “[^a-zA-Z0-9]”, “”, “all”);
#I would use a DB call, but for a few to a few hundred sites, this maybe better
#We are looking for a Config File for their “site”
var configFilePath = expandPath(“./config/” & cgi.HTTP_HOST & “.cfm”)
#Do Stuff if you find the file
if (fileExists(configFilePath)) {include configFilePath;
#Else Do something else
Yeah segmented sites all running off the same webroot, pointing all assets off to S3 etc
Even a DB call in on application start would be absolutely fine, performance wise.
There are many ways to skin a cat!
2 Likes