Has anyone ever attempted to persist the framework in the SERVER scope instead of the APPLICATION scope? The reason for this idea is that we have a SaS model which creates a unique APPLICATION scope for each client and right now, we have 50+ clients. Each of our production CF servers has 3 separate JRun instances in order to break the memory into smaller, more manageable pieces. As a result, we get 150+ caches copies of the framework per production CF scope (that’s a ton!). We would like to reduce this down to 1 single framework cache per JRun instance if possible. Is there a pitfall to doing this that I am not seeing? Would this require us to customize the framework? Thanks in advance for your comments.
-Micah
If the application name is the same, then you will only have one copy of the framework.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Social: twitter.com/lmajano facebook.com/lmajano
Hi Luis,
In our situation, the application name is different for every client because each client has their own database so we have to set a different ORM datasource for each application. Any advice on how to store the framework in the SERVER scope?
Thanks,
Micah
Honestly, I’ve never tried this, but you’d need to use the non-inheritance version of Application.cfc and stick the framework in server instead of application. You’d also probably need to add some server-level locking around the creation of the framework and add an exists check.
From there you’d need to find any place that accesses the framework from the application scope and change it to the server scope. Start by searching for COLDBOX_APP_KEY for starters-- basically you have to find everywhere we did this:
return application[COLDBOX_APP_KEY];
You’d have to modify the core framework code of course, which means you can’t automatically upgrade. Also, keep in mind that WireBox’s default scope registration is application.wirebox, so you’d probably need to change that too.
Once you got it working you’d basically have to test it and see how well it works 
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Hi Brad,
Thanks for the info. The fact that implementing this change would prevent us from being able to do automatic upgrades is definitely a roadblock. Is there a place where I can submit this request as a feature enhancement for the framework? I would envision there being a “scopeRegistration” configuration option for the framework similar to what is currently available for WireBox and CacheBox. This would give us the flexibility of building our app now and then migrating to the SERVER scope registration later, assuming the feature request is accepted.
Thanks,
Micah
Micah,
One trick you can do, that isn’t obtrusive on the framework, is to write a small library that does all this work for you. The downside is that it can’t be apart of ColdBox, but you could easily change the application name and other things based on information coming from the DB or a single file.
This depends on how you application currently works, or is about to work. But changing the application name and datasource on the fly is a trick I have been doing for 10 years now.
I wrote something about it for ColdBox and ORM on my blog, but the basics should give you enough to take it from there.
http://www.andyscott.id.au/blog/writing-a-coldbox-application-to-handle-more-than-one-site-with-orm-support
Andrew,
Thank you for the guidance. After reading your blog post it seems the method you described requires you to create a separate domain class for each site you want to run, regardless of whether or not the schemas are identical. Is this correct? If so, this would be a roadblock for us as we have some 200 tables in each client database that are exactly the same and we would prefer to reuse our domain classes across all clients for efficiency.
Thanks for the suggestion about writing a small library to store the framework in the SERVER scope. I’ll explore that.
Thanks,
Micah
Actually not really, that post was about how you could provide site only ORM and have ORM data shared across the sites. The principle is the same, just don’t follow the part about ORM if the DB is going to be identical. In your case you just need to change the Application name and the datasource.
In your case you just still will have an instance of ColdBox per application, but depending on the traffic to the site, you won’t notice much of a difference.
I wrote an application a few years ago, that used this method for a number of sites. The total heap size for ColdFusion 9 used up by the entire application, was around 800mb which was around 15 sites using the same code base. With user activity and load testing, I have never seen this heap raise above 950mb. Prior to this application being written in ColdBox the application was crashing with out of heap space about 5 times a week. Which from memory was around 50k visits a month, so not a huge site, but certainly needed the change.
Just something to think about as well.
Yeah, we currently have the app set up to change the application name and the ORM datasource based on the HTTP_HOST and it is working beautifully. Based on your experience, we may run into some performance challenges because of the fact that we will have an instance of ColdBox in memory for each client (50+ at this point in time). We are going to pursue this architecture for now and do some load testing to see how it performs. Thanks again for the feedback.
-Micah
Let me know how you go, I don’t see 50+ being too much of an issue, but think about shared hosting and how many sites they may run on one server it is probably a lot.
As you control the servers, I don’t think you will be seeing more servers for a number of years yet.
Brad/Micha,
return application[COLDBOX_APP_KEY] is only in ColdboxProxy.cfc – the majority of other instances, appKey or a appKey getter of some description is used: application[appKey], application[locateAppKey()] or application[ controller.getAppKey() ] ….etc etc.
I’m also interested in loading coldbox into the server scope, but it looks like a major overhawl – I’ve spotted at least 80 instances, along with applicationStart hooks and everything else 
Tom.
Sure, sign up for a free JIRA account and create tickets all you like!
https://ortussolutions.atlassian.net/browse/COLDBOX
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com