Browse Prior Art Database

Balanced Control Protocol for Hybrid Database System

IP.com Disclosure Number: IPCOM000034582D
Original Publication Date: 1989-Mar-01
Included in the Prior Art Database: 2005-Jan-27
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Ciciani, B: AUTHOR [+3]

Abstract

An improved transaction rate at high levels of data contention is achieved in a hybrid centralized-distributed database system when the control protocol balances aborted transactions resulting from local and central site conflicts. Transactions in the hybrid system are classified after preprocessing into class A, a purely local transaction with updated data propagated asynchronously to the central site, class B, usually requiring remote data and shipped in their entirety to the central site, and class C, occasionally requiring remote data and run locally with data requests directly to the remote system. The database is partitioned among the distributed systems, replicated at the central site, and each distributed system is concurrency and coherency control master for its database partition.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Balanced Control Protocol for Hybrid Database System

An improved transaction rate at high levels of data contention is achieved in a hybrid centralized-distributed database system when the control protocol balances aborted transactions resulting from local and central site conflicts. Transactions in the hybrid system are classified after preprocessing into class A, a purely local transaction with updated data propagated asynchronously to the central site, class B, usually requiring remote data and shipped in their entirety to the central site, and class C, occasionally requiring remote data and run locally with data requests directly to the remote system. The database is partitioned among the distributed systems, replicated at the central site, and each distributed system is concurrency and coherency control master for its database partition. For class A transactions, data are accessed locally and local locks are requested for data required (shared or exclusive mode). The lock manager maintains a concurrency control field used with usual locking protocols to insure granting of compatible lock requests and queuing of incompatible requests, and a coherency control field to maintain a count of updates being sent to the control site and initially set to zero. At transaction commit point, a check first is made to see if the local transaction has been marked for abort by a committed central transaction. If so, the locks held by the class A transaction are released and the transaction started over; if not, the concurrency control field is used to release the shared or exclusive lock by the transaction (queued transactions can then be granted the lock) and the coherency field count is incremented to indicate a pending response from the central site. An asynchronous message is sent to the central site indicating locks released by the transaction and a copy of the resulting updated locks. Upon response by the central site that the message was processed, the coherence field message count is decremented. Meanwhile, the local transaction completes without waiting for the message transmission or response. A succeeding local transaction can lock and update the data, increment the coherence count and send another update message before acknowledgement of the earlier message.

These mesages may be batched to reduce overheads, but communications protocol must insure processing in the order of origination. If this is not done, higher level protocol must insure if a transaction commits and has locks on items with a non-zero coherence count, then asynchronous messages to the central site are queued until previous messages are acknowledged. Class B transactions are shipped to the central site where they access replicated local data. The central site uses local locks for concurrency control among i...