• Nem Talált Eredményt

THE DECENTRALIZED TRANSACTION ORDERING ALGORITHMS (R0SE73,GARD7S) tHowever, y

UNUSED OR USED BY OTHER QUEUES

VIII. THE DECENTRALIZED TRANSACTION ORDERING ALGORITHMS (R0SE73,GARD7S) tHowever, y

The previously presented algorithms were based on a locking schema^the voting algorithm is based on a detection of obsolete time stamps. The following algorithms are also based on a detection of illegal ordering of accesses to resources. These algorithms have been described for databases which are not duplicated, but they can be used in such an environnement. However, they need virtual locking (BERN7S) of all the available copies used by a transaction. They are based on a detection of interferences with restart of one transaction when an interference occurs. They can be used as centralized or decentralized algorithm.

In this section, we present our algorithm with decentralized control . Then, the (R0SE78) algorithms are discussed as variants of this algorithm which proceeds as follow :

(a) when a transaction is initiated, the original controller gives it a serial identification number unique in the network; simple technique to do that have been described in (LELA78) and (LAMP78); then, the original controller send an initial message including this identification number to all the active sites where the transaction needs to operate;

(b) each controller manages a table of the transactions which are initiated on it;

when it receives the initiating message, it determines the lowest local serial number of the initiated transactions; then, it returns back this number to the original controller;

(c) the original controller determines the minimum of all the local numbers; this number is associated to the transaction and will be refered as the stable number;

(d) each resource is labelled with the serial number of the last transaction which has updated it;

(e) when a transaction tries to read or update a resource, the access is(see fig-ure 3 a) :

- accepted if the resource label is inferior to the transaction stable number or equal to the transaction serial number (access after updating),

- rejected in all the other cases; the transaction must then be roll-backed;

(f ) each concerned controller must be informed of the end of a transaction; the commitment of a transaction is locally performed by extracting its serial number from the table of the initiated transaction;

(g) when a site is inoperative, of course all the transactions which are initiated on it must be rol-backed; then the site can be ignored; when it has been repaired the recovery procedure must perform the accepted updatings and find a correct table of the transactions initiated on it by asking to all the sites which manage a copy of a part of its local database.

The (ROSE78) DIE—WAIT schema can be presented as a variant of the previous algorithm where step (e) is replaced by :

(e*) when a transaction tries to read or update a resource, the access is (see figure 3b) :

- accepted if the resource label is inferior to its stable number or equal to its serial number,

- delayed if the resource label is included between its stable number and its serial number,

- rejected in all the other cases; the transaction must then be roll-backed.

The (R0SE78) WOUNI>-WAIT schema can be presented as another variant where step (e) is replaced by:

(e") when a transaction tries to read or update a resource, the access is (see figure 3c):

- accepted if the resource label is inferior to its stable number or equal to its serial number,

- delayed if the resource label is included between its stable number and its serial number,

- accepted in all other cases but the transaction the serial number of which is the resource label must be roll-backed.

Both the (R0SE78) algorithms decrease the risk of roll-backs but need the management of waiting queues.

stable number serial number 1

GRANT j

DIE J

DIE

Figure 3a

stable number serial number GRANT 1

WAIT i DIE

Figure 3b stable number serial number

GRANT 1 WAIT

_... .

WOUND

Figure 3c

Figure 3 i Illustration of the transaction ordering algorithms

transaction behaviour. The SDD.1 updating methodology is quite different.

Interferences resolution is performed by the way of preanalysing the whole set of transactions with the help of a conflict graph. When the transaction programs are defined, the sets of resources they are able to read or write are specified. Then, a conflict graph is constructed as follow : each node correspond to a read or write set of resources and an undirected edge links two nodes belonging to a same transaction or two nodes representing non-disjoint sets of resources.

Four different synchronisation protocols are available. By the way of the conflict graph, transactions are classed in one of four classes, each of them corresponding to one level of protocols. The most efficient protocol specifies no inter-computer synchronisation at all; a transaction which runs under this class needs only perform local locking in order to ensure the convergence of the distributed database. This protocol can be used when no risk of interferences is detected with the help of the conflict graph. Each of the other protocol introduce some degree of non-local synchronisation. The less efficient protocol requires global locking of all the resources*

When a transaction is activated, a protocol selection function operates by mapping each transaction entered into a class and by selecting the adequate protocol* This function uses tables predefined by the database administrator.

The ultimate goal of this strategy is to reduce the number of messages inter­

changed to synchronise the transactions and to avoid global locking when it is possible.

34 X. CONCLUSION

Several algorithms have been described which can be used for updating redundant distributed databases* The choice of one is not obvious. Many criteria must be considered as :

(a) the degree of parallelism allowed in the distributed system;

(b) the completness of the proposed solution to the interference problem and to the subsequent one which are deadlock (G0LD77,MUNT78) and permanent blocking or cyclic restart (H0LT71,R0SE78)|

(c) the response time given to a transaction which performs an operation on a resource; it can vary from only a local computation to several messages exchanged on the network;

(d) the promptness for updating the copies of a resouce (GELE78);

(e) the cost of the message traffic generated (GARC78);

(f) the tolerance to different kinds of failures and the simplicity of restating after reparation;

(g) the degree of prevision required to the transactions; some algorithms need that each transaction forsee all the accessed resource before starting; others need to lock the resource before each operation; others have no such requirements;

(h) the cost in i/o time, processing time and memory requirement (for the lock tables, the time stamps.,,).

All these criteria may be important. The opinion of the author is that the weight of each is dependent upon the considered application. Consequently, each futur distributed database management system should be able to propose several methodologies; thus, the database administrator would be able to choose the best one for each application.

(ADIB78) M. ADIBA,J.C. CHUPIN,R. DEMOLOMBE,G. GARDARIN,J, LEBIHAN

"A technical overview of resarch and development in distributed systems"

4th international conference on Very Large Database BERLIN Sept 1978 (ALSB76) P« A. ALSBERG,G.G. BELFORD, S.R. BRUNCH

"Synchronization and Deadlock"

CAC Document Number 185- University of Illinois- March 1976 (BACH77) P. W. BACHMAN

"Advances in Database Technology"

Infotech State of the Art Tutorial - LONDON December 1977 (BERN77) P.A. BERNSTEIN,N. GOODMAN,J.B. ROTHNIE,C.A. PAPADIMITRIOU

"Analysis of serializability in SDD.1: a system for distributed databases"

Computer Corporation of America - Technical report N CCA-77-05 (BERN78) P.A. BERNSTEIN, D,W. SHIPMAN

"A formal model of concurrency control mechanisms for database systems"

3rd Berkeley Workshop on Distributed Data Management and Computer Networks Pp 189-205 August 78 - BERKELEY

(CHU74) W.W. CHU,G. OHLMACHER

"Avoiding deadlock in distributed databases"

ACM National Conference - Pp 156-160 - Nov. 1974 (DAVE78) R.A. DAVENPORT

"Integrity in distributed database systems"

Eurocomp 78 Pp 751-773 (ELLI77) C.A. ELLIS

"A robust algorithm for updating duplicate databases"

2nd Berkeley Workshop on Distributed Data Management and Computer Networks Pp 146-158 May 1977 - BERKELEY

86

"Currency and concurrency in the cobol database facility"

Modelling in DBMS»- North Holland Pub Co. Ed, by J. NIJSSEN Ррб2Д-бЗЗ 1976 K.P. ESWARAN,J.N. GRAÏ,R.A. L0RIE,I.L. TRAIGER

"The notion of consistency and predicate locks in a database system"

Comm. ACM - Vo119/11 - Nov 1976 Pp 62A-633 J.P. FRY,M.E. DEPPE

"Distributed database : a summary of research"

Technical Report 75DE-2 University of MICHIGHAN- ANN ARBOR 1975 H. GARCIA MOLINA

"Performance comparaison of two update algorithms for distributed databases"

3rd Berkeley Workshop on Distributed Data Management and Computer Networks Pp 108-122 August 1978 BERKELEÏ