This section provides answers to the most commonly asked questions related to Objectivity/DB services.
A lock server manages concurrent access to persistent objects by granting or refusing locks to requesting transactions. When a transaction requests data from a federated database, Objectivity/DB locates the lock server that services the federated database and then contacts the lock server to obtain a lock on the requested data. The lock is granted only if it is compatible with existing locks. Obtaining a lock prevents multiple concurrent transactions from performing incompatible operations on the same data, whether these transactions belong to different applications or to different threads of the same application.
On Windows, there are 3 ways that you can start/stop the lock server: On UNIX, you start the lock server by using oolockserver. To stop the lock server, you run ookillls.
You can check whether lock server is running on a particular workstation by using oocheckls.
Yes. You can list all locks and processes currently managed by the lock server. To do this, use oolockmon. You can use this information to determine the locking status on objects and to locate unexpected locks. If you find locks that are held by transactions belonging to terminated application processes, you can use oocleanup to release them.
You can list all active transactions that have locks on data in a federated database. To do so, run oocleanup with only the bootFilePath. You can use oolistwait with the bootFilePath and various options to list transactions that are waiting on any lockable Objectivity/DB object (federated database, database, or container). This tool also finds out whether a specified transaction is waiting for a lockable object, and if so, which transactions Federated Database Tasks Referencing Objects in a Federated Database currently hold the lock on that object. |
|||
 |
||||||||
|
||||||||
|
|