Browse Prior Art Database

Integrated Concurrency and Shared Buffer Coherency Control for Multi-Systems

IP.com Disclosure Number: IPCOM000060385D
Original Publication Date: 1986-Mar-01
Included in the Prior Art Database: 2005-Mar-08
Document File: 7 page(s) / 90K

Publishing Venue

IBM

Related People

Dias, DM: AUTHOR [+4]

Abstract

An integrated method for coherency control of a shared buffer and concurrency control using locking in a multi-system data-sharing environment is described. The use of the shared buffer leads to reduction in the transaction response time, reduced contention between transactions, and consequent higher transaction throughput. Combining the concurrency control using locking, with the coherency control of the shared and local buffers, eliminates broadcast notifies (as explained below), reducing the overhead and allowing a larger number of systems to be coupled. The basic system structure assumed here is illustrated in Fig. 1. A number of systems, each running an independent operating system, share a common database. Each system schedules transactions for execution locally. There are two levels of data sharing.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 15% of the total text.

Page 1 of 7

Integrated Concurrency and Shared Buffer Coherency Control for Multi- Systems

An integrated method for coherency control of a shared buffer and concurrency control using locking in a multi-system data-sharing environment is described. The use of the shared buffer leads to reduction in the transaction response time, reduced contention between transactions, and consequent higher transaction throughput. Combining the concurrency control using locking, with the coherency control of the shared and local buffers, eliminates broadcast notifies (as explained below), reducing the overhead and allowing a larger number of systems to be coupled. The basic system structure assumed here is illustrated in Fig. 1. A number of systems, each running an independent operating system, share a common database. Each system schedules transactions for execution locally. There are two levels of data sharing. All systems have access to a shared memory (SM), to secondary storage (disk), and to a centralized controller of concurrency and coherency. This controller, called the lock manager, uses locking to provide both functions. Here, the focus is on data coherency control of the shared memory. That is, all systems must see a consistent version of blocks in the local buffers, shared memory and disk. Current multi-system transaction processing systems do not use the shared memory, and operate essentially as follows [2]. (See Fig. 2.) In this context, a block is the unit of data transfer between the database disks and the processor's primary memory. A typical block is 4 Kbytes of data. At the end of a transaction, a log is written to non- volatile store (usually disk) and updated blocks are written to shared secondary storage (disk). Following this, broadcast notify messages are sent to all systems in the complex informing them of blocks that have been modified. Systems receiving this block invalidate message delete these blocks from their local buffers in main memory (Fig. 1) and respond to the requesting system that they have completed their buffer invalidation. If the block is being currently read from shared secondary storage, it will be declared as invalid at the completion of the read. After invalidation completion messages are received from all other systems in the complex, the transaction that did the update can release the lock it had on the updated block. Now any other system that needs this block must read it from secondary storage. Fig. 2 shows the actions for 3 blocks written at the end of the transaction (commit time). (This is the average number of writes per transaction observed in traces analyzed in [1].) Typically, these writes take about 30 milliseconds each, for a total of about 90 milliseconds. During this time all locks are held by the transaction. The shared memory buffer can be used to store updated blocks.(This would be done after writing a log to non-volatile storage for recovery purposes.) Now a transaction that does an update can rel...