The following is a proven example using the AllLongTransactionExclusiveLock type with multiple users and the Update command. When you connect to an Oracle data store, you are placed in the already-activated, default root long transaction. If a long transaction is created in root, it is considered a child of root. When the new long transaction is activated (for example, as LT1), the subsequent actions take place in the context of LT1. If another long transaction is subsequently created (for example, as LT2), it is created as a child of LT1.
This example considers two closely related cases. The same set of actions are taken in both cases, but in slightly different sequences, yielding different results. User1 creates a long transaction in the context of root and it is activated. User1 applies an AllLongTransactionExclusiveLock to a feature object in a data store. User1 updates that feature object in the data store. User2 attempts to update the same object, in the same data store, in the context of root. In the first case, User2 succeeds, and in the second case User2 fails (that is, a lock conflict is reported).
More specifically, the sequence of events for both cases is captured in the accompanying Long Transaction and Locking Sequencing Example diagram. For this example, all events occur in a single data store. The sequence of events are:
- User1 creates LT1, activates LT1, and updates feature object “a” in LT1.
- User2 successfully updates object “a” in root.
- User1 creates LT2, activates LT2, and updates feature object “b” in LT2.
- User2 fails to update object “b” in root.
The key difference is that, in LT1, User1 updates feature object “a” before the lock is applied, and, in LT2, User1 applies the lock to feature object “b” before it is updated. Prior to update, a copy of object "b" has not been made in LT2. This causes the lock to be applied to the copy of the object in root, because there is not yet a copy in LT2.
Therefore, if User1 intends to prevent anyone from modifying the object from the root level, User1 must apply the lock to the object before updating it.
For more information about Oracle Workspace Manager and its lock management, see the Oracle documentation.
Long Transaction and Locking Sequencing Example