No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
DEADLOCK DETECTION AND RECOVERY IN DISTRIBUTED DATABASE SYSTEMS.
Abstract
A discussion is presented of the detection and the recovery of deadlock in distributed database systems. A distributed algorithm D**3 is proposed first for deadlock detection, and has the following four features: (1) each site maintains and updates only local information, where no information in other sites is needed; (2) the message to be exchanged among the sites for deadlock detection is of fixed-length and simple; (3) as the ratio of local transactions (access to the data in only one site) is increased, the communication required to detect the deadlock becomes less; (4) the processing in each site is simple and can easily be implemented on hardware. As the next step, time-complexity, area-complexity and communication complexity of D**3 are evaluated. Finally, for the case where D**3 detected a deadlock, the recovery from the deadlock is described.
... At present there are a number of methods for prevention, avoidance and detectionrepairing of the deadlocks (see [9,32,10)). Very often deadlock detection methods are based on distributed maintenance of the "wait-for-graph", that shows which process is waiting for a resource held by which other process [13,28,5,26,27). Deadlock detection is reduced to finding cycles in this graph. ...
For many years software engineers have been providing the engineers of other fields with advanced design tools. But the tools used by software designers themselves look quite primitive in comparison. Only CASE-like systems developed during last years can provide reasonable help to software developers. Experimental software development systems ALADDIN/LAMP is oriented to creation of distributed computer control systems (DCCS). Proposed approach to development distributed software configurations (DSCs) is based on the model of virtual distributed software configuration (VDSC) with information-transport ports (ITPs) as interconnecting servers. Transputer networks and OCCAM-written software are often used for creation of DCCS. An approach to ALADDIN/LAMP tools-extention for OCCAM-written DSCs handling is discussed in this paper. Survey of tools is presented (OCCAM-oriented structure editor OSE, OCCAM structure extractor OSX, ALADDIN/OOB translator and deadlock locator and analyser DLA). A comparison with related works is given.
One of the most important problem, which arised during the creation of distributed software configurations (DSCs) for parallel systems and distributed computer control systems (DCCS), is deadlocks between interacting processes. Deadlocks are the subject of research, because their influence on normal computer systems behaviour is obvious. In the DCCS oriented software development system ALADDIN/LAMP during DSC debugging and maintenance the problem of deadlocks elimination also was faced. Programming language OCCAM was designed for development of DSCs runing on the transputer networks. This paper deals with the problem of DCCS software components operation reliability increasing by means of deadlock analysis and elimination. As the most important OCCAM language features as the approach to ALADDIN/LAMP tools extention for deadlocks analysis in OCCAM-written DSCs are presented.
A new multiversion concurrency control scheme for a distributed database system is proposed in this paper. Each data object in our database model has two copies allocated in different sites in the system. Unlike the usual distributed database systems with redundant copies, these two copies are not concurrently updated, but only one is updated for a write request. For each data object, the copy with a newly updated value is called the new version and the other is called the old version. Since two versions are accessible for each read request to an object and concurrent update of two copies of each data object is not necessary, our scheme allows increased concurrency. Our concurrency control scheme employs both timestamp mechanism and locking mechanism with two different modes which is based on the (r,a,c)-locking protocol proposed by Bayer et al., and it grants a version for every read request without causing inconsistency. Transactions with write requests which would cause inconsistency are aborted. It has been proven that our concurrency control scheme works correctly; namely, it preserves consistency without deadlock or livelock among operations of the transactions in the system.
ResearchGate has not been able to resolve any references for this publication.