Distributed Resultset caching in GeneXus

Official Content

The diagram below summarizes the behavior of the distributed cache for web applications (and web services, including the REST Web Services which are the business tier of a Smart Device application).

For detailed information on this topic refer to ResultSet caching in GeneXus

Consider a fictitious scenario where a web application user selects an option in the web page to load the customers list.

DistributedDataCachingPicture1

  1. An HTTP request to the web page is sent to the web server.
  2. Once the request is processed by the server, the distributed cache is queried. The distributed cache stores pairs (key, value), where the key is the SQL query including the parameters. The validity of the cache depends on the Change frequency property set for the involved table.
  3. If no valid data is present in the distributed cache for this query (including the parameters), a database connection is used to query the database.
  4. The distributed cache is updated with the result set obtained from the database, and the timestamps are adjusted.
  5. The web server processes the result and sends the response to the client.

Let's see what happens the next time any user makes a request for the same list of customers.

Distributed Data Caching Picture2

  1. An HTTP request to the web page is sent to the web server.
  2. Once the request is processed by the server, the distributed cache is queried using the query itself as the key to search for any entries in the cache. Since there is a valid entry in the distributed cache for that query, there's no need to establish a connection to the database.
  3. The web server processes the result and sends the response to the client.

In a real scenario, a query can involve more than one table; so for this mechanism to work the Change frequency property of all those tables is considered.


Was this page helpful?
What Is This?
Your feedback about this content is important. Let us know what you think.