Concurrency
Concurrency
Objectivity/DB supports regular ACID (Atomicity, Consistency, Isolation and Durability) transactions. Lock Server processes grant access to processes or threads that need to read or write a database construct. The Lock Servers implement hierarchical Gray-code locking semantics. A strong write lock (X) on a container results in a weaker write lock (IX) on the database it is in and on the federation that contains the database. This allows other users to write into different containers in the same database. Figure 6 (below) shows how Objectivity/DB automatically propagates locks “upwards” on behalf of the application. The S, X and IX locks were obtained on behalf of the User 1 and 2 requests.
Objectivity/DB uses an underlying container versioning mechanism to allow other readers to continue seeing the committed version of a container while it is being updated. This mechanism (Multi-reader, One-Writer mode) considerably reduces the number of locks that a process must acquire by eliminating the need for object level locking. It also increases throughput by allowing both readers and the writer to run at full speed.
Objectivity/DB also allows databases to be cataloged as “read only”. This eliminates the need to send messages to the Lock Server(s) when accessing this kind of database.
Although automatic hierarchical locking and Multi-reader, One-Writer mode reduce the amount of lock traffic it is still sound practice to:
- Acquire update locks as late as possible in a transaction
- Do as much as possible to a group of related objects in a single transaction.
Despite the above mechanisms for reducing the amount of Lock Server traffic, it is still possible to overwhelm a single processing node with message traffic. Objectivity/DB allows the databases in a federation to be divided into groups, called Autonomous Partitions, with each of the groups controlled by its own Lock Server. This reduces the traffic to individual processors and increases the resilience of the system.
Long distance Lock Server traffic can be avoided by situating a Lock Server within a LAN that supports a group of local client processors. Ideally, the databases would all be local too, but the physical locations of servers and databases can be set independently of one another. Figure 7 (below) shows a partitioned environment.
A single Lock Server would also be a single point of failure, so splitting the domain of control (and hence the traffic to individual Lock Servers) also increases the fault tolerance of a system. The failure of a single Lock Server will only affect local users. Fault tolerant configurations are discussed again later.
Application developers can cluster objects of the same or different types together at multiple granularities – database, container and logical page. Designers can set default clustering policies, such as “always put a new Sentence object near the most recently created Paragraph object”, but the policy can be overridden whenever the need arises.
Careful grouping of objects that are frequently accessed together into their own containers or databases also reduces the number of lock requests. Putting all of the objects (Paragraph, Sentence, Word) objects for a particular Book object in the same
container, as shown in Figure 8 (below) would require a single lock, rather than putting the Paragraphs and other object types of object in their own containers or databases.
Application servers often control single databases or groups of databases. An application server process can be directly linked with its own In Process Lock Server, avoiding the need for network traffic. This configuration is frequently chosen when Objectivity/DB is embedded in telecom, process control or automation equipment.
Another aspect of concurrency, i.e. cumulative load on networks, data servers and I/O devices, is covered in the sections on Input/Output Capabilities, Caching and Network Bandwidth.