How to add Items to the Cache Application Data on Server

How to add Items to the Cache Application Data on Server

  
Hi guys,

I need to save information on server cache to be accessible to all users of my application. I can't store this on Session, because other users won't be able to access it. 

Googling around I found the Caching Application Data of .NET, so I wondered to create an extension to it, but I had no success yet...

Any ideas?

Thanks!
 
Hi André,

Have you taken a look at Cache In Minutes property? It'll use the cache in memory for each Front-end, so it is not user session related. Will it work for your scenario?

Cheers,
Pedro
Unfortunately it doesn't work for my scenario Pedro, just because the elements that can be cached are the following (below), and I need to store a text on the server memory to make it available externally (and for 10 sec) .
I'll try to explain it better: When my user log in my application, a key-token is generated and stored for 10 sec. This token will send only for registered domains that request an information. So anyone who makes a request to my app will need this key-token to be validated. If I store this key-token on the Session, external requests (like web services) will not be able to access it.

The good news is that I managed to implement an extension for this using the MemoryCache Class from .NET. I'll publish on the forge as soon as possible and post here the link.

Thanks!






 

Solution
Hummmm... couldn't the User-defined Action with a Text output parameter do that work for you?

Furthermore, you could have stored the key-token in an entity referencing UserId and with a DateTime attribute, being then (both) returned by the cached action, so you could control token expiration. I'm pretty sure this implementation (or similar approaches) has been done in lots of OutSystems projects before. But glad you made it on your own. Congrats!
Solution
Hello Andre. Just be careful when storing tokens in memory: it won't work in farm scenarios, because the token will be stored in only one of the nodes.

You should check if your solution should support a farm with two or more frontends. If so, the solution suggested by Pedro of storing the token on the database seems like a good alternative.
Good point Leo. You are right, I'll check if we have a farm scenario to avoid this behavior.

If so, I'll try the solution you suggested, Pedro. 

Thanks!
Finally I published the component in the forge:

http://www.outsystems.com/forge/component/1054/MemoryCache/

Best regards,
André Siébra

Pedro Gonçalves wrote:

Hi André,

Have you taken a look at Cache In Minutes property? It'll use the cache in memory for each Front-end, so it is not user session related. Will it work for your scenario?

Cheers,
Pedro

Hi Pedro,

Will this work for Farm scenario?

For use cases where we want to prevent excessive server action calls by rate limiting, we will need to have a temporary cache (work in the farm deployment) to keep track of number of requests from individual mobile app users. What would be ideal solution for this type of use case? I feel database is overkill.


Hi Gadar. I don't think any approach that uses memory cache will work in farm scenarios.

Why do you think a database access is overkill? That would be the best way to get consistent data across all frontends.

If you don't need data to be consistent, then you can use the in-memory cache in each frontend. Each frontend will have a different cache, but you just need to find a timeout that works for you - not too small as it wouldn't bring any benefit, but also not too big as it would create inconsistencies between frontends.

Hi Gadar, we do have some guidelines and components for distributed caching, in case you're interested. I believe they are meant to fit farm scenarios. Have you checked the article Improving performance with distributed caching? It suggests a distributed memory cache broker (dmCache) component from Forge which supports several database engines. Please note though, that this approach will increase your infrastructure size, so it's worth evaluating cost-benefit as suggested in previous posts (e.g. Leonardo's). Regards!