As I posted earlier, I was having some funkiness with XStandard caching data and showing up duplicates of stuff. I had originally thought that since my debugging (my custom XStandard configuration) was turned on, it was some how hamstringing XStandard on LARGE SOAP responses. I found out that this is not the case; after a temporary fix, the weirdness came back.
I think I have finally found a solid fix. If I put a random variable in the URL for the web service call, it seems to work well:
- <!--- Attachment library. --->
- value="...[long url]...&rand=#RandRange( 1, 1000 )#"
The randomness of the "rand" URL parameter forces the server and the browser (or whatever XStandard's internal mechanism is) to think the web service call is unique and therefor cannot use any kind of caching mechanism. Now, this is not for EVERY web service call; the randomization only occurs when the browser is first loaded... but, this seems to take care of the problem.
I have had this in place for a day and so far nothing out of the ordinary. Now, again, I don't know how XStandard works under the hood, and I am not convinced this was the correct solution or that it has anything to do with this, that, and the other. For all I know, me restarting my computer last night could have been the fix. Either way, it's all good at the moment.
Looking For A New Job?
- Part-time remote DBA needed at Bridge
- Senior Developer Wanted for International Cloud Company at Giva, Inc.
- ColdFusion Developer - jQuery, PrimeUI, ORACLE DB at ComSpec International, Inc.
- Jr. ColdFusion Developer - Full Time / Telecommuting is ok. at InterCoastal Net Designs
- CF Engineer with Big Data Hadoop experience. at Border City Media