New persistence API in Infinispan 6.0.0.Alpha4

The existing CacheLoader/CacheStore API has been around since Infinispan 4.0. In this release of Infinispan we've taken a major step forward in both simplifying the integration with persistence and opening the door for some pretty significant performance improvements.

What's new

So here's what the new persistence integration brings to the table:

• alignment with JSR-107: now we have a CacheWriter and CacheLoader interface similar to the the loader and writer in JSR 107, which should considerably help writing portable stores across JCache compliant vendors
• simplified transaction integration: all the locking is now handled within the Infinispan layer, so implementors don't have to be concerned coordinating concurrent access to the store (old LockSupportCacheStore is dropped for that reason).
• parallel iteration: it is now possible to iterate over entries in the store with multiple threads in parallel. Map/Reduce tasks immediately benefit from this, as the map/reduce  tasks now run in parallel over both the nodes in the cluster and within the same node (multiple threads)
• reduced serialization (translated in less CPU usage): the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly

API

Now let's take a look at the API in more detail:

  The diagram above shows the main classes in the API:

• ByteBuffer - abstracts the serialized form on an object
• MarshalledEntry - abstracts the information held within a persistent store corresponding to a key-value added to the cache. Provides method for reading this information both in serialized (ByteBuffer) and deserialized (Object) format. Normally data read from the store is kept in serialized format and lazily deserialized on demand, within the MarshalledEntry implementation
•  CacheWriter and CacheLoader  provide basic methods for reading and writing to a store
• AdvancedCacheLoader and AdvancedCacheWriter provide operations to manipulate the underlaying storage in bulk: parallel iteration and purging of expired entries, clear and size. 

A provider might choose to only implement a subset of these interfaces:

• Not implementing the  AdvancedCacheWriter makes the given writer not usable for purging expired entries or clear
• Not implementing  the AdvancedCacheLoader makes the information stored in the given loader not used for preloading, nor for the map/reduce iteration

If you're looking at migrating your existing store to the new API, looking at the SingleFileStore  for inspiration can be of great help.

Configuration

And finally, the way the stores are configured has changed:

• the 5.x loaders element is now replaced with persistence
• both the loaders and writers are configured through a unique store element  (vs loader and  store, as allowed in 5.x)
• the preload and shared attributes are configured at each individual store, giving more flexibility when it comes to configuring multiple chained stores 

Cheers,

Mircea