Hmmm....tricky! 1) How do you determine if it is corrupt? Um.... if it throws a "Retrieval of cached query failed" error, then it's corrupt! I know it's a cop-out answer, but we haven't been able to find any other way - you don't seem to be able to CFCATCH the error.
2) What makes a cached query corrupt? Well, the situation in 3) in my original response is one way - there's probably many others. Here's a quote from Greg Gauthier (Allaire Sr. Tech. Support Engineer) in the forums - "This error typically happens in one of three cases: 1) If you were trying to insert a query into a full cache where all of the queries were being used you'd get the error. 2) Another place where this could happen is if the cache max size is set to zero and you try to cache a query 3) Finally this occurs when global access to the cache is granted initially, but because the page timeout has been reached the retrieval fails. " Does the page where this error occurs take a long time to run? Alistair Davidson Senior Developer Rocom New Media www.rocomx.net "There is no spoon" -----Original Message----- From: Tim Stadinski [mailto:[EMAIL PROTECTED]] Sent: 29 October 2001 15:38 To: CF-Talk Subject: RE: failed retrieval of cached queries Of all the points you have made, I agree about the locking issues, but that is not the case here. One point that I am curious about (6)If the cached query is corrupt.... How can you determine if it is corrupt and what makes a cached query corrupt? Thanks Tim -----Original Message----- From: Alistair Davidson [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 3:50 AM To: CF-Talk Subject: RE: failed retrieval of cached queries Hi Tim I don't know how much of this response will be relevant to your situation, but here's how we managed to resolve this problem - (apologies if any of this seems patronising, but I don't know what level to aim at here, so I'll explain everything!) We had this problem, and it was driving us absolutely nuts for months. Yeah, sure, some of our old sites (written before any of the current developers had joined the company) had some dubious locking strategies, but the errors kept being thrown on our NEW sites, which used REQUEST variables rather than APPLICATION variables, and had EVERY read/write to a shared scope inside a CFLOCK. After many LOOOOOOOONG head-scratching hours, we finally worked out that the following situation could occur - 1) Some old sites were using statements like this - <cfquery name="qry_productfeatures" datasource="#DSN#" cachedwithin="#APPLICATION.querycachetime#"> 2) Although WRITES to the application variables were cflocked, statements such as the above were not. 3) If that CFQUERY statement was run at exactly the same time as APPLICATION.QueryCacheTime was being set, then the query would still be executed and the resultset cached, but the time for which to hold the resultset in the cache could be corrupt. 4) "New" sites were also running statements like this <cfquery name="qry_productfeatures" datasource="#REQUEST.DSN#" cachedwithin="#REQUEST.querycachetime#"> against the same datasource as the old sites, and just occasionally, the SQL might match exactly. 5) The CF engine checks to see if it already has a query called qry_productfeatures on that datasource with the same SQL. If it does, it checks the current time against the cached query's cache time, to see if the query has expired. 6) If the cached query is corrupt, then the <cfquery...> statement does NOT return an catchable exception - the CF server keeps trying to retrieve it, and eventually (after about 60 seconds, in our case) it gives up, and the CF sub-system throws an error WITHOUT returning execution to your template. 7) For all the time that the engine is trying to retrieve that query, the thread used to process that request is unresponsive. It does NOT timeout at the "Timeout request at X seconds" setting in the CF administrator. 8) If this is on a frequently hit page, it can very easily clog up the whole thread pool, and leave your CF server unresponsive. 9) The only way to free up the threads again is to bounce the CF service. Conclusions ----------- 1) DON'T use application variables if you don't have to! Use the Request scope instead. 2) If you HAVE to use application variables (e.g. to store complex persistent structures that are based on huge DB queries that take ages to run), then Duplicate() the application structure into the REQUEST scope in your application.cfm, like this - <cflock name="(some name)" timeout="2" throwontimeout="YES"> <cfset REQUEST = Duplicate( APPLICATION )> </cflock> 3) Make sure ANY references to shared scopes are inside a lock of the same name (or scope) as the writes to those variables. Enforce this on a CODE level- don't rely on the "Automatic locking" setting in CFAdmin, because this only checks <cfset ...> statements, and DOES NOT catch implied reads like the <cfquery ...cachedwithin="#APPLICATION.QueryCacheTime#"> statement. Hope that helps Alistair Davidson Senior Developer Rocom New Media www.rocomx.net "There is no spoon" -----Original Message----- From: Tim Stadinski [mailto:[EMAIL PROTECTED]] Sent: 25 October 2001 22:12 To: CF-Talk Subject: failed retrieval of cached queries Has anyone seen the following error: CFQuery Retrieval of cached query failed<p>The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (401:3) to (401:153) in the template file.... I have posted this on the forums, but have not got a response and it seems like there are others with similiar issues. thanks in advance. Timothy Stadinski Afternic.com [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
