Deciding the Persistence Data Storage Strategy
The persistence data storage strategy creation process involves the following decisions:
>Knowing the Persistence Types
>Understanding the Persistence Data
>Selecting Appropriate Data Storage Layouts
>Using the Custom Persistence Device API
Knowing the Persistence Types
Persistence types are used for categorizing the persistence data of different licensing models. The available persistence types are:
|
Persistence Type |
Parameter value |
|---|---|
|
CPD_TYPE_TRIAL |
1 |
|
CPD_TYPE_REVOKE |
2 |
|
CPD_TYPE_COMMUTER_CLIENT |
3 |
|
CPD_TYPE_COMMUTER_SERVER |
4 |
|
CPD_TYPE_GRACE |
5 |
|
CPD_TYPE_CONSUME |
6 |
|
CPD_TYPE_NETWORK_REVOKE |
7 |
|
CPD_TYPE_TIME_TAMPER* |
8 |
| CPD_TYPE_USAGE_LOG | 9 |
| CPD_TYPE_USAGE_GUID | 10 |
| CPD_TYPE_USAGE_LOG_NONET | 11 |
| CPD_TYPE_CANCEL_LEASE_STORE | 12 |
| CPD_TYPE_ROLLOVER_COUNT | 13 |
| CPD_TYPE_USAGE_LOG_COMMON | 14 |
Understanding the Persistence Data
Before deciding a persistence data storage strategy, you should understand the structure of the persistence data. The persistence data consists of the following parts:
>Persistence Type: Used for categorization of a data record on the basis of different licensing models.
>Key: Used (in combination with persistence type) to identify and retrieve data records. Recommended storage allocation for key value is 40 bytes.
>Data: The data is stored as an encoded character stream of variable length. The length of data will be determined by the persistence type of data. The minimum and maximum length of data can vary between 78 bytes to 5909 bytes (across different persistence types).
The developer must use a combination of persistence type and key for storing and retrieving the persistence data.
Selecting Appropriate Data Storage Layouts
Based on a developer’s implementation, persistence data for all persistence types can be stored in one or more storage objects.
Case 1: Storing the persistence data for all persistence types in a single storage object.
|
Persistence Type (P TYPE) |
Key |
Value |
|---|---|---|
|
Type 1 |
K2 |
V2_XXXX |
|
Type 2 |
K1 |
V1_XXXX |
|
Type N |
Kn |
Vn_XXXX |
|
Type 1 |
K1 |
V3_XXXX |
In this case, the developer must use the combination of persistence type and key as a composite key to identify the persistence record. Similarly, this composite key can also be used for retrieving the persistence data for a particular persistence type and key combination.
Case 2: Storing the persistence data of different persistence types in separate storage objects.
|
Key |
Value |
|---|---|
|
K2 |
V2_XXXX |
|
K3 |
V3_XXXX |
The developer is using a multiple storage object-based strategy. For example, a single storage object is storing the persistence data related to a particular persistence type. In this case, the key value is used for identifying the persistence record.
|
Key |
Value |
|---|---|
|
K1 |
R1_XXXX |
|
K5 |
R5_XXXX |
For example, the usage scenarios explained in case 1 and case 2 can be implemented using a database as the persistence storage device. The developer can either use single or separate tables for storing the persistence data of multiple persistence types.
Refer to the sample program “cpd_sqlite.c” for a detailed description on using external data storage (sqlite database) for storing the persistence data of multiple persistence types. This sample implements the usage scenario described in case 1.
Using the Custom Persistence Device API
The available API are categorized into the following categories:
|
These API are provided by Sentinel RMS for configuring the custom persistence device for storage. These API should be called before any another API to enable custom persistence device feature. |
|
|
These API are implemented by the developer to define various tasks related to persistence data storage. |