Locking & Concurrency
Locking & Concurrency
Access by concurrent transactions is supported by automatic locking of individual objects.
Any number of images may connect to a virtual space, and any image may connect to any number of virtual spaces, constituting a disjoint family set, one of which is designated to contain the transaction log.
Multiple users may thus connect to virtual spaces either by having the application run in VOSS-enabled images on the desktop connected to the file-server(s), and/or by connection to a VOSS-enabled image serving each remote user by a separate Smalltalk process.
VOSS implements automatic pessimistic locking on all objects which are sent a message during a transaction. An explicit shared or exclusive lock may be requested on an object (before any other message is sent to it) by the messages #setReadLock or #setWriteLock respectively. A transaction releases all its locks when it commits or rolls back.
Whenever a message is sent to a virtual object it is locked on behalf of the current transaction (usually the most recently started) of the current process, by either a shared read-lock or an exclusive write-lock depending whether the transaction is read-only or read-write. If the object is already locked by a transaction belonging to another process in the same image or in another image on the same or another machine, the waiting process re-tries the lock continuously until either the lock is granted or a user-defined time-out limit is reached; only then does it signal a lock time-out exception, which follows one of several courses of action, such as rollback and retry, depending on the interactive mode and other settings.
Object locking is thus fully automatic and applications may be written substantially as for a single-user, without the need for explicit handling of temporary lock conflicts by the application; however explicit locking control for individual objects is also provided for special circumstances, such as hot-spot management.
There are two user-selectable degrees of transaction isolation:
Degree 3 is complete isolation (”repeatable read”) - read/write transactions hold exclusive locks until commit/rollback, read-only transactions hold shared locks until rollback.
Degree 2 sets exclusive locks in read/write transactions the same as degree 3, but read-only transactions set short read locks, i.e. the lock is released after the message which set the lock has returned. The object may therefore be seen and changed by other concurrent transactions, improving concurrency, but any subsequent message to the same object in the receiver’s process will re-read such a changed object and see it in its changed state, whether or not it has been dropped from the cache in the meantime. Since objects which are not locked in the cache are dropped from the cache to make room for others, this is the preferred isolation degree for large read-only (e.g. report-generating) transactions.
Degrees 1 and 0 are not supported.
