Tips for Locks
The example LockExample (in BE_HOME/examples/standard) demonstrates these points, showing use of locks to prevent race conditions.
- Choose an appropriate key for lock(). Note that lock() does not lock any entity or object as such. The purpose of lock() is to ensure sequential processing of related set of objects, but yet ensure concurrent processing of unrelated objects. For example, you want to process messages related to one customer sequentially across the cluster, but want to process messages for different customers in parallel. In this case you could use the customer ID as the key used for lock(). This ensures that all messages for a given customer ID are processed sequentially.
- Do not use unchecked and infinite waits (-1) on the lock. The recommended approach is to use the timeout argument, and then exit with an error.
- Always check the return value of lock() and if false, either retry or handle it as an error. Don't let application logic proceed if it returns false. Doing so may result in lost updates or stale reads or other such data inconsistencies.
- Try to minimize the locks acquired in one thread. If you have to acquire multiple locks in one thread, ensure that the locks are acquired in the same order of keys, that is, sort the keys.
- Acquire locks before creating instances, to ensure that no other thread creates the same instance.
- Use lock() even for read-only operations. If you do not you may get “Inconsistent Database” messages, for example, if there are concurrent deletes elsewhere in other threads or agents.
- In general, avoid using lock() in a rule. Since rule order of execution is not guaranteed such usage may lead to deadlocks.
Copyright © Cloud Software Group, Inc. All rights reserved.