- We need to document the new Persistence (Cache Store) API of Infinispan 6.0 for JDG 6.2, so that customers can use this superior API to implement custom cache stores. Although we don't support custom cache stores, we to make this Persistence (Cache Store) API available as a documented public API. - The older Cache Store API can still remain for legacy uses, but the customers need to be able use the new API to create that own cache store for HBase, Cassandra, etc, storing data in the desired format. - We should also document how the compatibility mode format could be leveraged to preserve values of an entry when writing with a (custom) cache store, so that data is not stored as a binary blob and can be processed meaningfully by HBase, Cassandra, etc.
We should probably also have a very clear indicator in the custom cache store docs that despite documenting the new persistence API, we do not support using custom cache stores (which is what the new API does) as this may be confusing for customers.
This is not documented in community yet. Once it will be available (ISPN-3616) we can build on top of that.
*** Bug 921368 has been marked as a duplicate of this bug. ***
Removed need info for Tristan. Send email to Mircea to help estimate when this information will be available.
1. I think an example with both a custom store and an provided store makes sense as people use both 2. Look for "An external persistent storage might be useful for several reasons" here[1]. That should some background on why the persistence API is used. [1] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_persistence
Thanks Mircea. 1. I'll add the custom cache store (lib) config and get your views on what (if anything) needs to be changed. Not sure what a provided store is, though. Tristan, can you clarify what a provided store is and whether we include/support it since Mircea is on PTO? 2. Thanks, added.
Additionally, one of the requirement is: - We should also document how the compatibility mode format could be leveraged to preserve values of an entry when writing with a (custom) cache store, so that data is not stored as a binary blob and can be processed meaningfully by HBase, Cassandra, etc. We don't have any information on how to do this, so I'll wait and check with mircea when he returns from PTO. Or perhaps if Tristan knows, he can fill in the blanks.
Acked the Pad. When mmarkus mentions "provided store", he means one of the stores we package (singlefile, jdbc, remote, rest, leveldb) Compatibility mode does not actually mandate any format, it is merely a framework for automatically converting entries between the formats expected by the different access modes (embeddded, hotrod, etc). A custom cache store has access to the "raw" key/values in the cache and therefore can be programmed to understand those values and write them to the persistent backend of choice using an appropriate schema. Examples: - if the value is a POJO, a custom cachestore can obtain data from it (provided it knows its type) - if the value is annotated with JPA annotations, a custom cachestore could use JPA itself to write data to the persistent store in a schema-aware fashion - if the value is structured text (e.g. XML, JSON, etc), a cachestore could parse it to extract the actual items of data.
Attempting to find an example of some sort where we use this API to configure a custom or other supported cache store. Checking with Tristan. Not sure details in comment #14 satisfactorily address the last requirement for this item. Will investigate further but probably track in a separate bug for a later release.
This bug is ready and will be QA'd as part of the comprehensive docs QA for this release.
The fix for this bug is now generally released and available here: https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.2/index.html