Transaction and Concurrency Control Instructions
The Jade instructions for transaction and concurrency control are listed in the following table.
| Instruction | Purpose |
|---|---|
| beginTransaction | Indicates the start of a transaction that updates persistent objects |
| beginTransientTransaction | Indicates the start of a transaction that updates shared transient objects |
| commitTransaction | Commits changes made within a transaction to storage |
| commitTransientTransaction | Releases all transaction duration shared transient locks and exits from transient transaction state |
| abortTransaction | Aborts the current transaction |
| abortTransientTransaction | Releases all transaction duration shared transient locks and exits from transient transaction state |
| beginLoad | Starts a read-only transaction |
| endLoad | Ends a read-only transaction started with the beginLoad instruction |
| beginLock | Starts a read-only transaction, ensuring referenced objects are the latest editions |
| endLock | Ends a read-only transaction started with the beginLock instruction |
The beginLoad and endLoad instruction pair and the beginLock and endLock instruction pair perform similar functions. They enable you to defer the unlocking of locked objects to the end of the operations bounded by the beginLoad and endLoad instructions or the beginLock and endLock instructions. One endLoad or endLock instruction enables you to unlock all of the objects locked during a sequence of operations bounded by these instructions.
The difference between the two instruction pairs is that the lock pair automatically places a shared lock on all objects that are referenced, whereas the load pair leaves it to you to decide and code the objects that are locked. Therefore, if the object is already in cache and you do not place a shared lock on it or use some other means of forcing the latest copy into your local cache when using the load instruction pair, reading this object will use the copy in cache, which may be out of date.
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.
For more details about object editions, see "Unlocking Objects", in Chapter 6. For details about reading and writing transactions, see "Using Read and Write Transactions", in the following subsection. See also "Sharing Uncommitted Persistent Objects", later in this section.
