Browse Prior Art Database

Shared Memory Management for Transaction Speed-Up in a Multi-System Environment

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

Publishing Venue

IBM

Related People

Dias, DM: AUTHOR [+3]

Abstract

A method for controlling a shared buffer in a multi-system data-sharing environment that results in significant transaction speedup and reduction in contention between transactions is described. The decrease in contention allows the multiple systems to sustain a higher transaction throughput. A larger number of systems can be coupled together using this scheme, than without it. In addition, transaction response time is significantly reduced, as described below. 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. There are two levels of data sharing. All systems have access to a shared memory and to secondary storage (disk). Each system schedules transactions for execution locally.

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 14% of the total text.

Page 1 of 7

Shared Memory Management for Transaction Speed-Up in a Multi-System Environment

A method for controlling a shared buffer in a multi-system data-sharing environment that results in significant transaction speedup and reduction in contention between transactions is described. The decrease in contention allows the multiple systems to sustain a higher transaction throughput. A larger number of systems can be coupled together using this scheme, than without it. In addition, transaction response time is significantly reduced, as described below. 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. There are two levels of data sharing. All systems have access to a shared memory and to secondary storage (disk). Each system schedules transactions for execution locally. It will be assumed that concurrency control of these transactions is done using locking. This may be through a centralized lock manager or through a distributed lock management scheme [1]. The focus here 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 release locks after writing the block in the shared memor...