Unlocking Objects
You can unlock objects manually. Use the
Objects that are requested to be unlocked after a beginTransaction, beginLoad, or beginTransientTransaction instruction are not unlocked until a commitTransaction, endLoad, commitTransientTransaction, or abortTransaction instruction. (For details about read and write transactions, see "Using Read and Write Transactions" under "Transaction and Concurrency Control Instructions", in Chapter 1.)
All persistent object updates must be preceded by a beginTransaction. As objects are updated, the Jade Object Manager maintains a list of modified objects. At commitTransaction, all modified objects are passed back to the server and all locks are released, starting the server transaction. If the application does an abortTransaction, the list of modified objects is discarded and all locks are released. (For details about sharing uncommitted persistent objects, see "Sharing Uncommitted Persistent Objects", in Chapter 1.)
A commitTransaction instruction implies both an endLock and endLoad instruction.
In persistent transaction state, all unlock requests for persistent objects are ignored. Similarly, in transient transaction state, all unlock requests for shared transient objects are ignored. A session lock is therefore not released if the unlock request is made while in transaction state. To release a session lock, the unlock request must be made while not in transaction state.
Shared transient objects are automatically locked as they are updated within a transient transaction. The locks on these objects are released at the next commitTransientTransaction instruction.
Updates to shared transient objects are applied when the commitTransientTransaction instruction is executed. (For more details, see "Transaction and Concurrency Control Instructions", in Chapter 1.)
Use the beginLock and endLock instructions to bracket a read-only transaction, and ensure that objects referenced after executing the beginLock instruction and prior to the endLock instruction are the latest editions of the objects and remain unchanged during that interval. As objects are referenced, an implicit shared lock is acquired on each object, which causes the latest edition to be fetched from the server, if required.