Object Locking
Party and item entities provide the capability for locking and lock management. This is useful in a context where multiple concurrent processes are all working on the same object but it is necessary to control the order of access to the object in a defined sequence.
It is important to note that the Fulfillment Subscriber Inventory locking functionality does not provide any logic or rule-based checking of operation invoke against an object. It will only register a list of locks of interest, and publish the lock notifications in a controlled sequence. If clients do not respect the object locks, there are no hard rules within the Fulfillment Subscriber Inventory system to prevent the clients from accessing or updating the object out of sequence. Failure to respect the locking functionality may violate business requirements and result in an inconsistent state within the Inventory system.
- Lock Requests
The Lock requests will provide support to the following criteria: - Lock Notifications
The granting of a lock or the expiry of a lock is asynchronous. It is necessary for client applications to have channels to receive lock notifications. Fulfillment Subscriber Inventory uses JMS topics to receive lock notifications. There are three topics per channel. They are: - Lock Modes
Fulfillment Subscriber Inventory supports two modes of locking. You can configure the modes of locking as per your requirements. - Create With Lock
You can use SOAP API to create an entity with immediate Lock in place. - Prevent Concurrent Update
The following diagram illustrates the concurrent aspect of locks: - Get with Lock Delayed
The following diagram provides additional details related to the immediate or delayed locking mechanism: - Admin Update When Not Lock Owner Permission
If you are a user with administrator privileges you need not own a lock to update the entity.