Warning! This documentation is a work in progress. Expect things to be out of date and not actually work according to instructions.

Caching

Stallion includeds Ehcache as a dependency and uses it internally in various places. Ehcache stores everything in the local memory of the Java service (and thus the caching information will not surive reboots).

Here are some of the places where caching is built-in:

  • If a data access controller is registered with the LocalMemoryStash, all rows are synced from the database into local memory. These items never expire.
  • If a data access controller is registered with the PartialStash, the most recently updated 10,000 rows are loaded into local memory. These items never expire.
  • When ever controller.filer() is run to build a FilterChain(), the results are stored in a cache for 45 seconds.

Stale content is prevented via the following logic.

  1. Every time during a request when a given table is accessed for the first time, iff there has been no check in the last 15 seconds, all rows updated sync the last check are synced into local memory.
  2. Every time during a request when a given table is accessed for the first time, if the user has made a POST, PUT, or DELETE request in the last 15 seconds, then all rows since the last check are synced into local memory.
  3. When an object is saved, the filter cache for that object’s controller is expired.

Also, the DB object has both methods that use caching and that ignore caching. If you use the methods with caching, the results are stored for 45 seconds. Caching is ignored if the user has made a POST, PUT, or DELETE request in the past 15 seconds.

The net result of all this logic is:

  1. If you get pounded by unexpected traffic, for instance, thousands of public visitors hammering your home page every second, virtually all of those requests will be served from the cache.
  2. If a user edits something in your app (which will always be a POST or PUT request), they will never get the stale version in a subsequent request.
  3. If you edit a value in the database directly, users will see the changes within 15 seconds.

The above logic covers 99% of the use cases for caching. You do not want to go down if you get an unexpected burst in traffic, you want to handle the most common requests more efficiently, but you don’t want people editing stuff to see stale content.

There are use cases where the above logic breaks down or creates problems. In those cases, you will have to implement your own caching strategy based on your exact use case.

If you want to use caching yourself you can always use Ehcache directly, or you use our thin wrapper, io.stallion.services.LocalMemoryCache

import io.stallion.services.LocalMemoryCache;

// Set a key, get a key
LocalMemoryCache.set("myKey", myThing);
assert myThing.equals(LocalMemoryCache.get("myKey");

// Set a key in a custom bucket, with a 30 second timeout
LocalMemoryCache.set("myBucket", "myKey", myThing, 30000);
assert myThing.equals(LocalMemoryCache.get("myBucket", "myKey");

// Expire all items in a bucket
LocalMemoryCache.clearBucket("myBucket");

© 2024 Stallion Software LLC