A {@link org.jboss.cache.loader.CacheLoader} implementation persists and load keys to and fromsecondary storage, such as a database or filesystem. Typically, implementations store a series of keys and values (an entire {@link Map}) under a single {@link Fqn}. Loading and saving properties of an entire {@link Map} should be atomic.
Lifecycle: First an instance of the loader is created, then the configuration ( {@link #setConfig(org.jboss.cache.config.CacheLoaderConfig.IndividualCacheLoaderConfig)}) and cache ( {@link #setCache(CacheSPI)}) are set. After this, {@link #create()} is called.Then {@link #start()} is called. When re-deployed, {@link #stop()} will becalled, followed by another {@link #start()}. Finally, when shut down, {@link #destroy()} is called, after which the loader is unusable.
An {@link org.jboss.cache.loader.AbstractCacheLoader} is provided as a convenient starting placewhen implementing your own {@link org.jboss.cache.loader.CacheLoader}.
It is important to note that all implementations are thread safe, as concurrent reads and writes, potentially even to the same {@link Fqn}, are possible.
@author
Manik Surtani (manik AT jboss DOT org)
@see CacheSPI
@see org.jboss.cache.config.CacheLoaderConfig.IndividualCacheLoaderConfig
@see org.jboss.cache.loader.AbstractCacheLoader
@since 2.0.0