[2014.13] having to constantly Purge Cached Queries because of 'method does not exist' error

Question

Question

Jason Ip · Jan 18, 2017

We've been noticing that we're getting this (https://community.intersystems.com/post/cach%C3%A9-sql-error-odbc) error more frequently and having to constantly purge cached queries in order to resolve it. Is there a way to avoid the issue in the first place?

thanks!

Discussion (7)0

Log in or sign up to continue

Nicole Aaron · Jan 18, 2017

Development did a code review and determined that this is a bug with the cached query generation code in Caché 2014.1. As far as I know we've only seen this for queries executed via xDBC.

There is a place in the cached query generation code where an error may not be properly trapped. In this case the cached query routines are not created properly, but no error is reported back. Then when Caché tries to use that cached query code to execute the query the expected methods do not exist.

The possible solutions we've come up with:

1. Create a task to purge cached queries in your application namespace - Pick a task frequency that means it will run more often than you have seen errors occur. This way you aren't stuck manually purging cached queries whenever an error pops up.

2. Get a development patch containing some fixes for your version of Caché - For this you will need to contact either your InterSystems Sales team or Support to file a WRC case. Note that our development patches do not go through our standard QD testing process. If you apply this patch you will be working with a version of our code that has not gone into any released product.

3. Upgrade your instance - This is the only long-term solution. Our cached query generation code has been rewritten in later versions of the product and this is no longer a problem.

1 0

John Hotalen · Jan 30, 2017

Also, I recommend using caution for when the cached queries are purged "dynamically". Purging cached queries dynamically can add risk to users running the application, such as incorrect/incomplete data and/or application errors. It is not a good practice to purge cached queries while users are actively using the application. If the cached query routines are deleted while a user is in the middle of having resultset data retrieved that could cause unwanted behavior. From what I understand of Cache Database Management, things like purging of cached queries should be done during slow/down times when users are not active on the system. Please feel free to confirm this with the InterSystems team.

Best of luck and Happy Coding....

0 0

score 0 · Answer 1 · 2017-01-18T13:40:47-05:00

Not enough information: What else is involved here? Mirroring? Shadowing? How is your namespace setup? Do you have routine mappings? Is it all the queries? Only some? Since when are you seeing the issue? What changed?

You could look at the journal files to see what/if the methods are being changed from another service.

You might want to consider opening up a WRC issue to get help tracking this down!

-Fab

score 0 · Answer 2 · 2017-01-18T16:34:59-05:00

Nicole,

Thanks for the detailed response, greatly appreciated.

A few followup questions to your answers:

1. how can such a task be created? what tool should I use and what method/entry point can I call? right now I've been manually doing it on the webGUI in the system management portal

2/3. I prefer the upgrading of my instance, do you know which version this was fixed in? 2015.x? or a later 2014.x?

thanks so much,

Jason

2.

score 1 · Answer 3 · 2017-01-25T10:51:59-05:00

1. You can create a new legacy task (allows you to run COS code) in your application namespace from the System Management Portal: http://docs.intersystems.com/cache20141/csp/docbook/DocBook.UI.Page.cls?...

The command to purge all cached queries in the current namespace is "do $SYSTEM.SQL.Purge()". That is described in our class reference here: http://docs.intersystems.com/cache20141/csp/documatic/%25CSP.Documatic.c...

2. I am checking in with development on which Caché version resolved this bug.

score 0 · Answer 4 · 2017-02-14T08:56:31-05:00

I spoke with development and the fix for this bug will not be in the product until 2017.1 versions and later. (However I also haven't seen this behavior reported outside of 2014.x versions.)

score 0 · Answer 5 · 2017-02-14T09:16:30-05:00

That was true in older versions of InterSystems products, when cached query code was stored in routines rather than classes. A problem could occur if a query executing in one process required round trips from the client to server and a separate process purged cached queries while the client application was still using it. Development resolved this by moving the cached query code into classes - the class definition and OREF are now stored in memory until the client process is done executing the query. This makes purging cached queries safe on a live system in more recent versions.

The change was implemented starting with Caché 2010.2.0 for dynamic SQL and Caché 2012.2 for xDBC queries.