Below is a diagram that summarizes the behavior of the distributed cache for online smart device applications.
For detailed information about this topic, refer to Native Mobile caching. This cache is activated through the Smart Devices Cache Management generator property and the Enable Data Caching object property.
Consider a fictitious scenario where the user of a smart device running a GeneXus-generated native application taps on an option to display the Work With Devices customer panel.
- An HTTP request is sent to the application server; for instance, to display the Work With Devices customer panel. This is the first time the user tries to execute this panel.
- A connection to the database is established to solve the query. The result set data is cached locally in the device.
If the query were an insert or update, the distributed cache would be updated with the table name and modification time stamp.
As a rule, the first insert or update query sent to the database table updates the distributed cache with the table name and the modification time stamp.
- Another request is executed for the same table (e.g., the panel that lists the company's customers). It sends, together with the query, the timestamp of the last reply (that is to say, the time when the query was last made).
- The distributed cache is queried using the table name involved and the timestamp mentioned in step 3.
- If the timestamp of the last query is greater than or equal to the timestamp in the distributed cache for the customers table, it means that the local cache has valid data. In this case, an HTTP 304 code is returned and the data is retrieved from the local cache in the device.
Otherwise, if the timestamp of the last reply were lower than the timestamp in the distributed cache for the customers table, the local cache would be invalid and another query to the database should be issued. In that case, the timestamp of the query should be updated on the client and the data should be updated on the local cache.
In general, the server must control whether any of the tables involved in the query has changed since the last query, in order to define what must be returned: either the local cache data or the result of a database query.
Note: The REST Web Services of the business logic of this architecture may use the Distributed Resultset caching in GeneXus also, for the business tier.