Force cache invalidation

Force cache invalidation

  
Hi!

Is there any way to force a cached query to get the results from the database on some condition?
(I bealive InvalidateCache() isn't an option)

The context is: I have a shared weblock that displays the number of unread messages, the query that gets the count of new messages is cached because every single page uses this web block.

There is a screen where the user reads a message and marks it as read. When this happens I need to invalidate that query's cache and force it to get the realtime results.

Any sugestion to accomplish this? Meanwhile I'm using this solution: the message count webblock checks for a session variable to see if it must use the cached query or nocache query. On message read event session variable is set to true.

Thx in advance
Hi José,

You can invalidate the cache of a query by passing different arguments to it (even if you don't use them). Using a dummy parameter that will only change when you need to invalidate the cache will probably work. 

Will that solve your problem?

Regards,
Hélio
Helio -

My understanding is that passing different parameters will NOT invalidate the cache, just create another cache for that set of parameters. I may be wrong.

If you really want to invalidate the cache for sure, call TenantInvalidateCache(), which is under "System" I believe.

J.Ja
Unfortunately, that clears everything in the cache, by the way... :(

J.Ja
Hi,

Justin is right. However, if the parameter works like a serial it won't ever have the same value twice, meaning that, changing it will always force the cache to have a new entry for the new parameter values. You may use a SiteProperty to store the parameter value and simply increment and send it as argument to the query to force adding cached values.

Kind regards,

jaime

Thank you both (Justin & Jaime) for the important information added. :)
If the list isn't too big, maybe another solution would be to store it in a session variable.
You'd have to check if the session variable has data before running the query (and not run the query if it does) and you can clear the session variable to "invalidate" it.
Hi Carlos,

First of all, session variables should only be used to store little information - which might not be the case with queries - because they are transported from and to the database in each request.
Second, you can only clear a session variable of the current session and not the other sessions, that is, you would only "invalidate" the cached values for one user and not all of them.

Regards,

jaime
Point 1: I did say, and I qoute "[i]f the list isn't too big". Also, the list can be quite big if the application only has a few concurrent users. Or if your server has loads of memory. Or if any other reason makes it a viable option.
As with everything, It's a trade-off.

Point 2: That might actually be the intended effect. Depends on what the list is, no?

And you forgot another reason not to use session variables: session variables are serialized/deserialized and that takes does take time to do. But again: depending on the actual use this may not be an issue.


Jaime Vasconcelos wrote:
Hi Carlos,

session variables should only be used to store little information
(...)
Second, you can only clear a session variable of the current session and not the other sessions, that is, you would only "invalidate" the cached values for one user and not all of them.
 
 
 
Hi,

just adding some info that may help.

https://www.outsystems.com/help/servicestudio/9.0/Improving_Runtime_Performance/Caching_Contents/Invalidating_the_Cache.htm