BeginLock

BeginLock(ACCESS, GRANULARITY)

199820

BeginLock, BeginLock(ACCESS), BeginLock(,GRANULARITY), BeginLock(ACCESS, GRANULARITY)

Stack

Stack	Object type
Stack (In)	-
Stack (Out)	-

Description

This command is used to control the page locking of ObjectStore. Each BeginTXN that starts a transaction sets the page locking to (UPGRADABLE, PAGE). When objects are accessed, the page of the objects is locked. For read accesses, the page is only provided with a read lock, which can become a write lock for later write accesses.

Locking is only defined within a transaction, so BeginLock opens a transaction if none was open yet. With BeginLock(WRITE), a write transaction is always opened. With BeginLock(UPGRADABLE), the type of transaction depends on the mode in which the database is opened. The set locking mode can be restored to the state before the last BeginLock with the EndLock command. BeginLock and EndLock can be nested as required. BeginLock does not work additively but replaces the last locking mode set with BeginLock completely with the specified mode. The set locking mode is only valid until the end of the transaction. At the end of the transaction all locks are released.

If the locking mode is changed, this only affects the locking of objects that were not touched before the BeginLock. All other objects already have a corresponding lock, which is only released again at the end of the transaction. BeginLock is also not to be understood as locking a page, segment, cluster, database, but it only sets the future locking behavior for this transaction.

Caution: BeginLock(WRITE) must not be used if the database is open in MVCC mode, otherwise access to persistent objects would request a Write-Lock, which is an error for MVCC databases.
So this concerns BeginTXN(READ) transactions and regular transactions in READ_ONLY databases.

As described in the next section, the write-lock mode can be used to prevent deadlocks, but excessive use of write-locks should be avoided. If the locked object is not written to the transaction at all, all other clients must still wait until the client with the lock has finished its transaction to read the object. This can seriously affect performance, and in this case the write locks do not prevent a deadlock.

Deadlocks

This command can be used to prevent deadlocks, which can occur quite easily with the UPGRADABLE lock. If two processes execute exactly the same code, the UPGRADABLE locks can cause a deadlock, because if two processes have already received a read lock for an object X, then neither of the two processes can receive a write lock for X, because all other processes must release their read locks on X first (lock rules). This procedure is illustrated in the following diagram.

Preventing deadlocks is the most common use case for BeginLock. In this case, it is sufficient to set the locking mode to (WRITE, PAGE) (default if not specified) before the initial loading of the object, so that the processes try to get a write lock on the first access. The ObjectStore server serializes the Write-Lock requests of the processes and one of them receives the Write-Lock, while the other one has to wait until the transaction of the first process is finished, so that the second one receives its Write-Lock. The deadlock is now lifted. This is illustrated in the next diagram.

Lock rules

To understand deadlock situations, it is necessary to understand how read and write locks behave. In the following we will talk about locks on objects, the smallest unit for which ObjectStore can assign a lock are pages. If an object is on the same page with other objects, then the entire page and thus the remaining objects are locked when the object is accessed.

Read-Lock: Can be held by any number of processes for the same object simultaneously. A read-lock can only be requested if there is no process that already has a write-lock on the object. Otherwise you must wait until the process has released the write-lock (end of transaction). With a read lock, an object can only be read, with a write access, the system tries to request a write lock for the object.

Write-Lock: Can only be held for an object by one process at a time. If a process already has the only read-lock on an object, then this read-lock can be converted into a write-lock. A write-lock can only be requested successfully if no other process holds a write- or read-lock on the object. Otherwise, you must wait until the locks are released (end of transaction). With a Write-Lock you can read and write to an object.

ACCESS values

ACCESS	Description
UPGRADABLE	If the first access to the object is read, then a read lock is requested, which can become a write lock for later write access.
WRITE	Default - The first time the object is read/written, a Write-Lock is requested directly for the object.

GRANULARITY values

GRANULARITY	Description
PAGE	Default - If an object is touched, only its page is locked.
CLUSTER	If an object is touched, then its entire cluster is locked.
SEGMENT	If an object is touched, its entire segment is locked. Use-Case: Batch run manipulates all objects of a segment and wants to make sure by locking the segment that no clients can lock single objects and thus stop the batch run in the middle.
DATABASE	If an object is touched, its entire database is locked. Use-Case: Database maintenance tools that must ensure that no other client is describing the database.