As of Qi4j 1.2, there is a caching abstraction available for the Persistence system. The Persistence Cache tries to be as light-weight as possible, so that it is very easy to create a Persistence Cache Extension.The Persistence Cache is optional for EntityStores to use or not. But since many EntityStores are actually MapEntityStore and JSONMapEntityStore implementations, they inherit this feature automatically. The Persistence Cache operates on a global cache per EntityStore, identified by the UUID of the EntityStore. The Cache itself has simple put, get and remove operations and Cache Extensions should be fairly easy to write.
Operation
When the EntityStore is to fetch an entity state from its underlying store, it should first check the cache and if found, read the value(s) from there. Then during the EntityStoreUnitOfWork.applyChanges(), the cache is updated with the new values after written to the underlying store.
Configuration
The configuration of the caching is implementation specific and part of the actual Cache Extension. To set up a Cache Extension, make available a CachePool service implementation to be visible to the EntityStore in question. Cache Extensions are optional by default.
UnitOfWork SPI
The SPI is not available to client code and unless you are implementing a Cache Extension, nothing you need to interact with.org.qi4j.spi.cache.CacheFactory
This is the entry point of the Cache Extension, used by UnitOfWork, and provided as a Qi4j Service.
public interface CachePool{ <T> Cache<T> fetchCache( String cacheId, Class<T> valueType ); void returnCache( Cache cache );
}
org.qi4j.spi.cache.Cache
The Cache itself is basically Map operations, and an additional destroy() method to delete the cache and have it removed from the heap.
public interface Cache<T>{ T get( String key ); void put( String key, T value );
T remove( String key );
}
Cache in MapEntityStore and JSONMapEntityStore
All the EntityStores that are utilizing the MapEntityStore and JSONMapEntityStore automatically gets the Cache support. The cache entries that will be written (and later read) are plain java.lang.String types, which are the JSON serialized values of the EntityComposite instances. So, the Cache Extension must be capable of handling String (not an unreasonable requirement). And by extension, this format is friendly to both cache to disk as well as setting up distributed caches.