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?
- 7 Year Lead Programmer with MSSQL expertise to assist in live website at Atprime Media Services
- .Net Developer at LendingUSA
- ColdFusion Application Developer / Portland Oregon at DealerPeak
- Web Applications Developer at University of California, Davis