Bug 1014420 - RFE: Add Persistence SPI information
RFE: Add Persistence SPI information
Status: CLOSED CURRENTRELEASE
Product: JBoss Data Grid 6
Classification: JBoss
Component: Documentation (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity unspecified
: GA
: 6.2.0
Assigned To: Misha H. Ali
:
: 921368 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-01 20:08 EDT by Misha H. Ali
Modified: 2014-01-15 19:02 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-15 19:02:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Misha H. Ali 2013-10-01 20:08:32 EDT
- 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.
Comment 1 Misha H. Ali 2013-10-01 20:09:51 EDT
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.
Comment 4 Mircea Markus 2013-10-30 11:17:15 EDT
This is not documented in community yet. Once it will be available (ISPN-3616) we can build on top of that.
Comment 5 gsheldon 2013-11-17 17:58:55 EST
*** Bug 921368 has been marked as a duplicate of this bug. ***
Comment 6 Misha H. Ali 2013-11-18 06:29:30 EST
Removed need info for Tristan. Send email to Mircea to help estimate when this information will be available.
Comment 10 Mircea Markus 2013-11-19 21:01:30 EST
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
Comment 11 Misha H. Ali 2013-11-19 21:50:08 EST
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.
Comment 13 Misha H. Ali 2013-11-19 21:55:33 EST
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.
Comment 14 Tristan Tarrant 2013-11-28 05:17:08 EST
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.
Comment 15 Misha H. Ali 2013-11-28 05:48:04 EST
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.
Comment 16 Misha H. Ali 2013-11-30 20:28:43 EST
This bug is ready and will be QA'd as part of the comprehensive docs QA for this release.
Comment 17 Misha H. Ali 2014-01-15 19:02:24 EST
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

Note You need to log in before you can comment on or make changes to this bug.