Overview on the Changes to the Persistent State Implementation
Currently it is technically possible (though not recommended) to share one persistent state database/database schema between different independent services. With future Runtime releases, this will not be allowed anymore.
Please find here an overview on the changes to the persistent state implementation. Refer to How to migrate a Persistent State DB used by multiple independent services for a detailed procedure how to migrate existing services that are concerned by this change.
Old | New | |
|---|---|---|
Supported databases |
|
|
Persistent state schema version | 15 | 16 |
Support for multiple services in one schema |
|
|
Support multiple instances of the same service in one schema |
|
|
Object Processing | ||
Type of multi-instance object processing | Exclusive. | Cooperative/Lock-based. |
 |  | |
Service instance becomes inoperative | All the objects assigned to the service instance stop processing. You need to manually assign the persistent state object to a different owner. | Other service instances (if any) automatically take over processing the objects after a short delay. |
Additional service instance is deployed | The new service instance only processes its own objects. If there aren’t any yet, it is idle. | The new service instance immediately starts processing existing objects. |
Dealing with database deadlocks | Deadlock do not lead to data loss. | Deadlock do not lead to data loss. Improved deadlock handling. |
What not has Changed
Signal Order
Regarding signal order and repetitions there has been no change in the persistent state implementation
Performance
The changes to the persistent state implementation have no negative effect on the performance. Extensive tests show that the performance of the new implementation may be even better than with the old one.