Question
Virtusa
IN
Last activity: 24 May 2024 8:28 EDT
Why Savable data pages scope is not having the node level.
Why Savable data pages scope is not having the node level.
-
Reply
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Updated: 24 May 2024 8:28 EDT
Eclatprime Digital Private Limited
IN
Hi @AbdulS3398 ,
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.
Eclatprime Digital Private Limited
IN
In Pega, savable data pages are used to load, manipulate, and save data to a data source, typically a database. The scope of data pages in Pega determines how and where data is stored and shared across different parts of the application. The available scopes are Thread, Requestor, and Node. However, savable data pages specifically do not support the Node scope for several reasons:
1. Data Integrity and Isolation - Concurrency Issues: The Node scope implies that the data page is shared across all users and sessions running on a particular server node. If multiple users or processes attempt to save data to the same data page simultaneously, it can lead to data corruption and inconsistencies. By limiting savable data pages to Thread or Requestor scope, Pega ensures that data manipulations are isolated to individual users or sessions, preventing such concurrency issues. - Isolation: Using Thread or Requestor scope ensures that changes made by one user do not inadvertently affect other users. This is crucial for maintaining data integrity, especially when different users might be working with the same underlying data sources but with different data sets.
In Pega, savable data pages are used to load, manipulate, and save data to a data source, typically a database. The scope of data pages in Pega determines how and where data is stored and shared across different parts of the application. The available scopes are Thread, Requestor, and Node. However, savable data pages specifically do not support the Node scope for several reasons:
1. Data Integrity and Isolation - Concurrency Issues: The Node scope implies that the data page is shared across all users and sessions running on a particular server node. If multiple users or processes attempt to save data to the same data page simultaneously, it can lead to data corruption and inconsistencies. By limiting savable data pages to Thread or Requestor scope, Pega ensures that data manipulations are isolated to individual users or sessions, preventing such concurrency issues. - Isolation: Using Thread or Requestor scope ensures that changes made by one user do not inadvertently affect other users. This is crucial for maintaining data integrity, especially when different users might be working with the same underlying data sources but with different data sets.
2. Session-Specific Data Handling - User-Specific Data: Savable data pages often involve user-specific operations, such as saving user preferences, updating case data, or submitting transactions. These operations are inherently specific to the user's session and should not be shared across the entire node. The Requestor or Thread scope ensures that data modifications are confined to the appropriate user context. - Transaction Management: Data operations within a session can involve multiple steps and transactions. Keeping the scope to Thread or Requestor allows better control over transactional boundaries, ensuring that operations are completed successfully before committing data.
3. Performance Considerations - Caching and Memory Utilization: Node-scoped data pages are stored in memory and shared across all users on the node, which can consume significant memory resources. Since savable data pages are typically modified frequently, caching them at the node level would result in frequent cache invalidations and high memory churn, impacting performance. - Load Balancing: Pega applications often run on multiple nodes for load balancing and scalability. Savable data pages scoped to a single node would not be consistent across different nodes, leading to potential data synchronization issues.
4. Practical Use Cases - Read-Only vs. Writable Data: Node-scoped data pages are ideal for read-only reference data that is infrequently updated and widely shared, such as lookup tables or configuration settings. Savable data pages, on the other hand, are intended for dynamic, user-specific data operations, where isolation and transactional integrity are paramount. - Scope Specificity: By limiting savable data pages to Thread or Requestor scope, Pega ensures that developers explicitly handle data operations in a controlled, user-specific context, reducing the risk of unintended data conflicts.
Summary Savable data pages in Pega are restricted to Thread or Requestor scope to ensure data integrity, isolation, performance, and proper handling of user-specific data operations. These scopes prevent concurrency issues, ensure session-specific data handling, and optimize memory and caching strategies, making them suitable for dynamic, user-specific data manipulation scenarios.
Eclatprime Digital Private Limited
IN
Hi @AbdulS3398 Savable data page has not node level because it is sharing the data across the application & node level has all the requestors level to participate. In nutshell if Pega will make savable data page as node level then those will make so much discrepancies, concurrency issue while saving the data because Node means its for all requestors in a application . So if each application will give its own data then Definitely it will give the multiple update of data which is a wrong practice so its only allows a user to update or save the data for different different threads.
Accepted Solution
Updated: 24 May 2024 8:28 EDT
Eclatprime Digital Private Limited
IN
Hi @AbdulS3398 ,
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.