Skip to main content

Cache Invalidation in OutSystems 11

OutSystems

Cache Invalidation in OutSystems 11

This article applies to:OutSystems 11

Caching allows applications to temporarily store a given subset of data so that further requests for the same data are done faster, since reading data from cache is a faster operation than reading it again from the database. Cached data of OutSystems applications is stored in the application server's memory.

Along with cached data itself, OutSystems also stores a reference to the module that produces that data or the tenant where that module exists. To refresh cached data, cache invalidation operations can be done for a module or for a tenant. This process will mark cached values in each front-end server as "dirty", and new values will be fetched from their original location when needed.

Whenever a request is made, the application server will get any data required for processing the request from memory and, if that data doesn't exist or if it's marked as dirty, it will be fetched from its original source.

How does it work?

The Cache Invalidation Service is the OutSystems component responsible for notifying front-end servers that cached values are not up-to-date, forcing them to fetch new values when needed.

This service uses a publish/subscribe pattern: applications subscribe to queues that represent modules and tenants where data can come from. The underlying technology used by the Cache Invalidation Service in OutSystems 11 is RabbitMQ, a distributed message queue service that implements the publish/subscribe pattern.

The platform must be properly configured so that applications can reach this service. You can install and configure a RabbitMQ instance using OutSystems Configuration Tool; this will install it in the same machine that is running the Configuration Tool. Check the Platform Server 11 Installation Checklist for more information on how to install and configure the Cache Invalidation Service.

Every time a cache invalidation occurs for a module or a tenant, all applications watching for changes on these elements will get notified, and they will flag their local copies as dirty. When the Cache Invalidation Service is down or unavailable (e.g. during configuration changes on this service), applications will not get notified of any cache invalidations that might have occurred. This may cause some inconsistent behavior until either these applications can reach the service again or new service configurations are applied. To improve the availability of the Cache Invalidation Service you can configure a RabbitMQ cluster and use a TCP load balancer.

  • Was this article helpful?