Closed jcberquist closed 4 years ago
I'm going to run this on my test environment for a while
I'm going to review this asap however right now its failing the older adobe builds. If those are valid fails then this will need to be reworked.
After further investigation it looks like the issue may be with the travisci process itself. I'll put this on my list to run on my test for a period.
@mjhagen Have you encountered any issues with this pull request. I have not seen any in my local testing.
Not consciously :) I've only had it on my dev environment, I could run it for some time in production if you want. But tests passed now, right?
Yup, all tests are passing. Im going to be adding this change to my own prod environment this weekend. I'd like to try run it in a prod like environment for 30 days and if nothing major shows up I'll approve this at the end of that period.
As it stands right now, every single request that comes in has to acquire the exclusive lock for the global fw1 app controller (i.e.
one.cfc
itself). There is also a race condition since each request sets its instance ofone.cfc
into the application scope via the cache (cache.controllers[ componentKey ] = cfc;
) and returns the cfc from the cache; it is possible that concurrent requests could overwrite the cache resulting in one of the requests returning the other request's instance ofone.cfc
. (I do doubt this would have consequences, but it is possible.)This change pulls the Application controller retrieval out of the locking mechanism, which it does not need since every request has its own instance and the application scope controller cache is not (supposed) to be involved. I retained the
autowire
call, but notinjectFramework( cfc );
since that would result in injectingone.cfc
into itself; I could add this back to ensure the behavior remains exactly the same. (Also note that the subsystem bean factory check can be ignored since Application.cfc does not get a subsystem bean factory.)