why there is no savable option for node scope in Datapage?
why there is no savable option for node scope in Datapage?
Accepted Solution
Hi @Satya K,
In Pega, Data Pages are used to load and cache data in memory for use in your application. The scope of a Data Page determines where the data is stored and how long it persists. The available scopes for Data Pages are:
-
Thread
-
Requestor
-
Node
However, you may notice that the Node scope does not have a "Savable" option, unlike the Thread and Requestor scopes. This is by design, and there are specific reasons for this behavior. Let me explain why:
1. What is Node Scope?
-
Node scope means the data is shared across all users and sessions on the same Pega node (server).
-
It is typically used for read-only, static, or infrequently changing data that can be reused by multiple users.
-
Examples: Reference data like country codes, currency rates, or product catalogs.
Hi @Satya K,
In Pega, Data Pages are used to load and cache data in memory for use in your application. The scope of a Data Page determines where the data is stored and how long it persists. The available scopes for Data Pages are:
-
Thread
-
Requestor
-
Node
However, you may notice that the Node scope does not have a "Savable" option, unlike the Thread and Requestor scopes. This is by design, and there are specific reasons for this behavior. Let me explain why:
1. What is Node Scope?
-
Node scope means the data is shared across all users and sessions on the same Pega node (server).
-
It is typically used for read-only, static, or infrequently changing data that can be reused by multiple users.
-
Examples: Reference data like country codes, currency rates, or product catalogs.
2. Why is there no "Savable" option for Node Scope?
The "Savable" option allows a Data Page to persist its data to the database so that it can be reloaded later, even after the server restarts or the cache is cleared. However, Node scope does not support the "Savable" option for the following reasons:
a. Node Scope is Shared Across Users
-
Node-scoped Data Pages are shared across all users on the same node. If the data were savable, it would introduce complexities in managing updates and ensuring data consistency across multiple users.
-
For example, if one user updates a Node-scoped Data Page, it could affect all other users on the same node, leading to potential conflicts or unintended side effects.
b. Node Scope is Designed for Read-Only Data
-
Node scope is primarily intended for read-only data that does not change frequently. If the data needs to be updated, it is typically refreshed from the source system or database.
-
Since the data is not expected to change often, there is no need to save it to the database.
c. Performance Considerations
-
Node-scoped Data Pages are cached in memory for fast access. Saving the data to the database would introduce additional overhead and latency, which goes against the purpose of using Node scope for performance optimization.
d. Alternative for Savable Data
-
If you need to save data persistently, you should use Thread or Requestor scope with the "Savable" option enabled. These scopes are user-specific and can safely persist data to the database without affecting other users.
3. When to Use Node Scope
Node scope is ideal for scenarios where:
-
The data is static or changes infrequently (e.g., reference data).
-
The data is shared across multiple users on the same node.
-
You want to reduce database calls and improve performance by caching the data in memory.
4. Example Use Case
Suppose you have a list of countries and their codes that rarely change. You can create a Node-scoped Data Page to load this data once and reuse it across all users on the same node.
-
Data Page Name:
D_CountryList -
Scope: Node
-
Source: Database or external system
-
Refresh Strategy: On startup or based on a time interval (e.g., every 24 hours).
Since the data is static and shared, there is no need to make it "Savable."
5. Summary
-
Node scope is designed for shared, read-only data that does not require persistence.
-
The absence of a "Savable" option for Node scope is intentional to avoid conflicts, ensure consistency, and maintain performance.
-
If you need to save data persistently, use Thread or Requestor scope with the "Savable" option enabled.
By understanding these design principles, you can choose the appropriate scope for your Data Pages based on your application's requirements.
Hope you understand
Thank you
Savable data pages in Pega cannot have a node-level scope because of potential data consistency issues in a multi-node environment. If you give access to the node level, a data integrity or data breach issue may arise.
Multiple Requestors: Node-level data pages are accessible by any requestor on the same node. If the data page were editable, multiple users could potentially modify the same data concurrently.
Locking Challenges: Implementing locking mechanisms to prevent conflicts in a multi-user scenario can be complex and resource-intensive. Pega avoids this overhead by restricting editability at the node level. Read-Only Suitability: Node-level data pages are typically used for storing reference data or common information that remains relatively static. Editability isn't a primary requirement for this use case.
Hi @Satya K ,
In Pega, a data page cannot be marked as "savable" when set to a "node" scope because it would create potential data inconsistency issues in a multi-node environment, where multiple requestors on the same node could potentially modify the data simultaneously, leading to data integrity problems; essentially, a node-level data page is meant to be read-only across all requestors on that node, not editable by any of them.
Regards,
Mohd Qizer Uddin
Accepted Solution
Hi @Satya K,
In Pega, Data Pages are used to load and cache data in memory for use in your application. The scope of a Data Page determines where the data is stored and how long it persists. The available scopes for Data Pages are:
-
Thread
-
Requestor
-
Node
However, you may notice that the Node scope does not have a "Savable" option, unlike the Thread and Requestor scopes. This is by design, and there are specific reasons for this behavior. Let me explain why:
1. What is Node Scope?
-
Node scope means the data is shared across all users and sessions on the same Pega node (server).
-
It is typically used for read-only, static, or infrequently changing data that can be reused by multiple users.
-
Examples: Reference data like country codes, currency rates, or product catalogs.
Hi @Satya K,
In Pega, Data Pages are used to load and cache data in memory for use in your application. The scope of a Data Page determines where the data is stored and how long it persists. The available scopes for Data Pages are:
-
Thread
-
Requestor
-
Node
However, you may notice that the Node scope does not have a "Savable" option, unlike the Thread and Requestor scopes. This is by design, and there are specific reasons for this behavior. Let me explain why:
1. What is Node Scope?
-
Node scope means the data is shared across all users and sessions on the same Pega node (server).
-
It is typically used for read-only, static, or infrequently changing data that can be reused by multiple users.
-
Examples: Reference data like country codes, currency rates, or product catalogs.
2. Why is there no "Savable" option for Node Scope?
The "Savable" option allows a Data Page to persist its data to the database so that it can be reloaded later, even after the server restarts or the cache is cleared. However, Node scope does not support the "Savable" option for the following reasons:
a. Node Scope is Shared Across Users
-
Node-scoped Data Pages are shared across all users on the same node. If the data were savable, it would introduce complexities in managing updates and ensuring data consistency across multiple users.
-
For example, if one user updates a Node-scoped Data Page, it could affect all other users on the same node, leading to potential conflicts or unintended side effects.
b. Node Scope is Designed for Read-Only Data
-
Node scope is primarily intended for read-only data that does not change frequently. If the data needs to be updated, it is typically refreshed from the source system or database.
-
Since the data is not expected to change often, there is no need to save it to the database.
c. Performance Considerations
-
Node-scoped Data Pages are cached in memory for fast access. Saving the data to the database would introduce additional overhead and latency, which goes against the purpose of using Node scope for performance optimization.
d. Alternative for Savable Data
-
If you need to save data persistently, you should use Thread or Requestor scope with the "Savable" option enabled. These scopes are user-specific and can safely persist data to the database without affecting other users.
3. When to Use Node Scope
Node scope is ideal for scenarios where:
-
The data is static or changes infrequently (e.g., reference data).
-
The data is shared across multiple users on the same node.
-
You want to reduce database calls and improve performance by caching the data in memory.
4. Example Use Case
Suppose you have a list of countries and their codes that rarely change. You can create a Node-scoped Data Page to load this data once and reuse it across all users on the same node.
-
Data Page Name:
D_CountryList -
Scope: Node
-
Source: Database or external system
-
Refresh Strategy: On startup or based on a time interval (e.g., every 24 hours).
Since the data is static and shared, there is no need to make it "Savable."
5. Summary
-
Node scope is designed for shared, read-only data that does not require persistence.
-
The absence of a "Savable" option for Node scope is intentional to avoid conflicts, ensure consistency, and maintain performance.
-
If you need to save data persistently, use Thread or Requestor scope with the "Savable" option enabled.
By understanding these design principles, you can choose the appropriate scope for your Data Pages based on your application's requirements.
Hope you understand
Thank you