Feature support with stateless DX API
DX API v1 is packaged under API service package. REST services under these packages are processed in a stateless manner. In stateless applications, when a request is fulfilled, the requestor that processes the request is terminated. Learn about the limitations of various features with stateless applications.
Preserve transaction integrity among cases by managing access to cases. Case locking strategies prevent loss of updates to cases that users make simultaneously.
In Pega Platform, you can lock a case in the following ways:
- Pessimistic – allow one user
- Optimistic – allow multiple users
For more information about case locking strategies, see Managing concurrent access to a case.
In the Pega Infinity software suite, when an application is configured to use default case locking, the system locks the case with the requestor before performing any action. This lock is released when the user terminates the session.
If you configure a pessimistic case lock in a DX API, the case lock will behave like an optimistic case lock where multiple users can access the case simultaneously.
Data pages and named pages
Named pages, requestor-level data pages, and thread-level data pages are associated with a requestor. These pages are not available after the request is served and the requestor is terminated.
Avoid using named pages, requestor-level data pages, and thread-level data pages with stateless DX API v1. If you use these data pages to set properties using pre or post-processing data transforms and activities, the data will not be available in the subsequent requests.
- Refresh endpoints only update fields in views. Any field that is not in a view is not available in the subsequent submit request.
- DX API v1 contains the following refresh endpoints:
Previous topic Differences between DX API v1 and DX API v2 Next topic Page-related operation queuing with page instructions