tracker issue | What iT iS dESign studios

Title:

[ANeff] Bug for: THIS.datasources changes ignored until CF restart

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 01/06/2015

Components: Database

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Normal / Some users will encounter

Locale/System: ALL / Platforms All

Vote Count: 2

Listed in the version 2016.0.0.297996 Issues Fixed doc

Verification notes: verified_fixed on August 06, 2017 using build 2016.0.01.298513

Changes to THIS.datasources are ignored until CF restart

Repro:

Application.cfc
---------------
component {
  THIS.name = "myApp";
  THIS.datasources.myDSN = {driver="MSSQLServer", database="mydatabase", host="www.domain.com", port=1433, username="username", password="password"};
  THIS.datasource = "myDSN";
}

index.cfm
---------
<cfquery name="q">
SELECT TOP 1 * FROM mytable
</cfquery>
<cfdump var="#q#">

1) Run the above code and see cfdump returns correct result
2) In Application.cfc's THIS.datasources and THIS.datasource, change "myDSN" to "myDSN2"
3) Run the above code and see exception: "Datasource myDSN2 could not be found." (bug)
4) In index.cfm, run applicationStop()
5) Run the above code and see exception: "Datasource myDSN2 could not be found." (bug)
6) Restart CF
7) Run the above code and see cfdump returns correct result

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3916906

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:  
External Test Config: Verified w/ CF11 Final and CF11 Update 3 (11,0,03,292480) on x64 Windows 8.1 Pro

Attachments:

Comments:

I have tried the steps mentioned above and I need not to restart CF server after changing the datasource/datasources name, calling applicationStop() function is working fine for me.

Can you please share the build number using which you are facing this issue?

I have verified it on CF #11,0,03,292480

Comment by Nimit S.

9090 | January 08, 2015 02:23:59 AM GMT

Hi Nimit,

I'm not sure if the "Test Configuration" portion of the ticket shows on your end, but yes I tested using 11,0,03,292480 as well as CF11 Final.  Here is the "Test Configuration" portion I'd put:

Verified w/ CF11 Final and CF11 Update 3 (11,0,03,292480) on x64 Windows 8.1 Pro

And that was w/ Standalone Enterprise.

Thanks!,
-Aaron

Comment by External U.

9091 | January 08, 2015 04:52:16 AM GMT

Nimit, are you suggesting that having to call applicationStop() is appropriate, in your opinion? It should not be necessary.

Comment by External U.

9092 | January 08, 2015 07:01:23 AM GMT

@Adam,

As per bug, calling applicationStop() is also resulting in error and we need to restart CF in order to get the expected result. But it seems to be working fine.

applicationStop() is required because all the variables get loaded during the application initialization and it will be an expensive task to re-create or check for any change in the datasource with every request.

Comment by Nimit S.

9093 | January 08, 2015 07:27:43 AM GMT

But hang on... code in the "pseudoconstructor" (outside any of the event handlers / interceptors) should be run every request. Indeed it *is* run every request.

Please don't tell me you've not implemented it such that only SOME of the pseudoconstructor code runs every request? Please.

Comment by External U.

9094 | January 08, 2015 07:38:36 AM GMT

That was my bad. I meant "datasources" struct gets loaded only once during the application initialization because it is an expensive task to re-create or check for any change in the data sources with every request.

Comment by Nimit S.

9095 | January 09, 2015 06:17:10 AM GMT

So are you telling me, given this code in Application.cfc:

this.mappings = {"/foo", "c:\foo};
this.datasources = {/*stuff here*/};

Then:
this.mappings gets loaded every request
this.datasources does not?

Comment by External U.

9096 | January 09, 2015 06:23:15 AM GMT

@Nimit,

If that's true, that's a pretty significant idiosyncrasy that I don't think is documented anywhere.  I can understand the need to not do it on each request, but it still is pretty scary that this is being done in the pseudoconstructor alongside other stuff that is being processed on **every** request.

It almost seems that it would have been more appropriate to handle this in the onApplicationStart() method, rather than the pseudo-constructor.  Although that might not be feasible either, as the setting is written into the application.cfc THIS scope, which is not writable from outside the pseudoconstructor?

Maybe a better solution is to add an optional boolean flag to the this.datasources setting to force it to be processed on each request.  The flag would default to FALSE, but when set to TRUE it would force the application to reinitialize the datasources on each request.  Obviously, you'd only want to set the flag to TRUE in development, not production.

**Regardless of whether the above is considered, it sounds like there is at least a bug with regard to applicationStop() not resulting in the this.datasources being reinitialized on the following request.

Comment by External U.

9097 | January 09, 2015 02:01:00 PM GMT

Please explain in 25 characters or more how this bug impacts productivity and why you are adding a vote.

Vote by External U.

9109 | January 10, 2015 03:24:51 AM GMT

I just tested this on Railo and new data sources are picked up immediately without any need to reload the application or the restart the server.  Removing a data source from Application.cfc also makes it unavailable right away.  I'd say this is the behavior to match.

I'll be honest, I don't understand the concern with reloading every request.  Was this a performance issue that was actually measured, or just assumed to exist.  I don't expect the actual data sources to be deleted and re-created every request.  I would expect you to create some hash or something that represents the current configuration.  Each page request only needs to compare the current config and see if it's changed.  If so, fix the data sources, if not just continue.  

It seems to me this could be implemented with very little effort and would only take a few microseconds to run the check.

Comment by External U.

9098 | January 10, 2015 03:42:27 AM GMT

Nimit?

Comment by External U.

9099 | January 25, 2015 06:58:40 PM GMT

Hi Nimit,

You're right, applicationStop() works and CF restart isn't necessary.

FYI, applicationStop() is simply ignored in the Application.cfc constructor area.  Bug?

Since code in Application.cfc's constructor area is expected to run on each* request, applicationStop() and THIS.datasources should follow suit IMO (Brad's idea should be used for THIS.datasources).  Otherwise, Carl's idea of a boolean flag should be used.  And applicationStop() shouldn't simply be ignored.

* - https://wikidocs.adobe.com/wiki/display/coldfusionen/Defining+the+application+and+its+event+handlers+in+Application.cfc

Thanks!,
-Aaron

Comment by External U.

9100 | January 28, 2015 05:26:20 AM GMT

Aaron/Nimit,

After further reflection, I like Brad's idea better - store a hash of the this.datsources structure internally and compare the hash each time application.cfc is run.  Only if the hash doesn't match the previously stored hash should ColdFusion then process the this.datasources.

Comment by External U.

9101 | January 28, 2015 10:26:33 AM GMT

"I promise you, however dark and scary the world might be right now... there will be light. There will be light, Bruce." - Det. James Gordon, Gotham

Vote by External U.

9110 | January 28, 2015 10:28:08 AM GMT

Agreed.

If there's overhead for CF to do processing every request, then  it's for the internals of CF to deal with that.

It should not impact the execution behaviour of the CFML code: the code should always run, but the results of the code might be cached (keyed on all the inputs the code has).

This is close to what's happening, I guess, just that the cached result is too aggressive, and doesn't consider the input-variation.

Comment by External U.

9102 | January 28, 2015 10:35:34 AM GMT

+1. We will take it up to fix.

Comment by Rupesh K.

9103 | January 30, 2015 10:20:44 AM GMT

Hi Rupesh,

This issue (a per-App setting not running on every request) is the same as CF-3121288 (another per-App setting not running on every request). Since this ticket is being fixed, can CF-3121288 also please be fixed in the same manner?

Thanks, BTW, for marking this ToFix and adding a comment.

Thanks!,
-Aaron

Comment by External U.

9104 | September 11, 2015 03:47:09 PM GMT

This issue is fixed and the fix for this issue will be available as part of next major release of ColdFusion.

Comment by Nimit S.

9105 | October 28, 2015 04:53:28 AM GMT

Thanks guys.

Comment by External U.

9106 | October 28, 2015 09:31:53 AM GMT

+1 thanks Adobe bods.

Comment by External U.

9107 | October 28, 2015 09:40:20 AM GMT

Verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513).

Thanks!,
-Aaron

Comment by Aaron N.

9108 | October 01, 2017 08:04:37 AM GMT

tracker issue : CF-3916906

[ANeff] Bug for: THIS.datasources changes ignored until CF restart