Persistent State Ownership
In Load Balancing context, when e.g. running multiple Bridges, you can setup persistent state services to share persistent state objects. The persistent state objects are distinguished by an owner and owner id reflecting the actual service that owns these objects.
Prerequisite is that these services share the same persistent state database, see Load Balanced Persistent State for more details.
To explain this in more detail, let's assume you have setup the following load balancing scenario:
BRIDGE 1 and BRIDGE 2 both have Service A deployed with same owner (Service A) but different owner ID s (9 and 7). The owner ID is generated automatically upon first successful service startup and stored in the service directory to file PersistentState.tab. Via owner and owner ID, all objects are related to the service they have been created by.
Services that have a matching owner can
- retrieve one another's persistent state objects
- send signals to one another's persistent state objects
- process (transition, do activities) objects with a matching owner ID only.
Examples:
- Service A (owner ID 9) can retrieve object data of Object 1 and Object 2. Likewise can Service A (owner ID 7).
- Service A (owner ID 9) can send signals to Object 1 and Object 2. Likewise can Service A (owner ID 7).
- A signal that has been sent to Object 2 by Service A (owner ID 9) will be queued and processed by Service A (owner ID 7).
- A signal that has been sent to Object 1 by Service A (owner ID 7) will be queued and processed by Service A (owner ID 9).
- Service A (owner ID 9) can process Object 1.
- Service A (owner ID 7) can process Object 2.
If one of the services is stopped, all of its objects will not be processed anymore. A redundant service can take over the processing of the persistent state objects, but will not do this automatically. To enable it to identify the persistent state objects to process, you need to change the owner ID of the objects to the one of the redundant service.
Example: Service A (owner ID 9) is stopped, all objects with owner ID 9 will not be processed (Object 1). You change the owner ID of Object 1 from 9 to 7. Service A (owner ID 7) processes Object 1.
Changing object ownership can be done on the Persistent State tab of the Bridge with button Manage Ownership, see below.
Manage Object Ownership
With button Manage Ownership on the Persistent State tab of the BRIDGE, you can change the owner ID of persistent state objects.
Clicking Take Ownership, the current service (owner ID 9) takes over the ownership of all objects related to the other owner (owner ID 10). In this case, this will be only one object as listed in column Objects.
If there is a different owner present, but this owner has no objects, the object count in column Objects will be 0 and button Take Ownership will be disabled.
This should only be done, if the previous owner service is not running.
If you try to take over the ownership of objects of a service that is still up and running, you will get a warning:
Click Take Ownership again, if you know what you are doing. Otherwise, click Cancel and stop the service first.
Changing the Name of an Owner
The load balancing example from further above on this page does not only work if multiple Bridges are involved. You can also deploy the very same service to the same Bridge with different names, e.g. Service A and Service A2.
To make the objects of Service A available for Service A2, you need to assign Service A and Service A2 the same owner name.
Upon deployment, the owner name will be the service name: Service A and Service A2. You can change the persistent state owner name of a service in the persistent state service settings:
To change the persistent state owner setting, the service must be stopped.
Be careful: If there are still objects existent that have been created with the old owner name, they will be orphaned afterwards.
You will not see them anymore on the Bridge, but they will still get deleted, if you select Delete All Persistent State Objects from the Persistent State tab.