Browse Prior Art Database

Protocol for Hybrid Centralized-Distributed Database System

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

Publishing Venue

IBM

Related People

Ciciani, B: AUTHOR [+4]

Abstract

Centralized and distributed database systems can be combined through control protocol to provide a hybrid system with improved efficiency that transmits necessary data to the central system, yet enables local processing as a distributed system. Replicated data at the central and distributed sites are controlled for consistency through protocol.

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

Page 1 of 2

Protocol for Hybrid Centralized-Distributed Database System

Centralized and distributed database systems can be combined through control protocol to provide a hybrid system with improved efficiency that transmits necessary data to the central system, yet enables local processing as a distributed system. Replicated data at the central and distributed sites are controlled for consistency through protocol. The protocol, through preprocessing, recognizes three classes of transactions: class A that are run on purely local systems with updated data propagated asynchronously to the central site; class B that usually require remote data and are shipped in their entirety to the central site; and class C that occasionally require remote data, run on the local system and request data directly from remote systems, replicated at the central site, and each distributed system is concurrency control master for its database partition. For class A transactions, data are accessed entirely from the system's database partition and requests are made for local locks for data required in either shared or exclusive mode. The lock manager maintains two fields for each lock, a concurrency control field to insure compatible lock requests are granted and incompatible lock requests queued, and a coherency control field to maintain a count of data updates being propagated to the central site and initially set to zero. At the transaction commitment point, the concurrency control field is used to release the shared or exclusive lock held, and queued transactions on the entity can be granted the lock. The coherence field count is incremented to indicate a pending central site response, and asynchronously a message is sent to the central site indicating released locks along with a copy of the data blocks being updated. This count is decremented when the central site responds that the message has been processed. In the meantime, the local transaction is completed without waiting. Another local transaction can lock and update the data, increment the coherence count, and asynchronously send another message to the central site before acknowledgement of the previous message. Asynchronous messages may be batched to reduce overheads, but communications protocol must insure that asynchronous messages are proces...