Ensuring Global Serializability in Software

Generate ANSI/AIM Code 128 in Software Ensuring Global Serializability

Early multidatabase systems restricted global transactions to be read only They thus avoided the possibility of global transactions introducing inconsistency to the data, but were not suf ciently restrictive to ensure global serializability It is indeed possible to get such global schedules and to develop a scheme to ensure global serializability, and we ask you to do both in Exercise 2415 There are a number of general schemes to ensure global serializability in an environment where update as well read-only transactions can execute Several of these schemes are based on the idea of a ticket A special data item called a ticket is created in each local database system Every global transaction that accesses data at a site must write the ticket at that site This requirement ensures that global transactions con ict directly at every site they visit Furthermore, the global transaction manager can control the order in which global transactions are serialized, by controlling the order in which the tickets are accessed References to such schemes appear in the bibliographical notes If we want to ensure global serializability in an environment where no direct local con icts are generated in each site, some assumptions must be made about the

The McGraw Hill Companies, 2001

24

schedules allowed by the local database system For example, if the local schedules are such that the commit order and serialization order are always identical, we can ensure serializability by controlling only the order in which transactions commit The problem with schemes that ensure global serializability is that they may restrict concurrency unduly They are particularly likely to do so because most transactions submit SQL statements to the underlying database system, instead of submitting individual read, write, commit, and abort steps Although it is still possible to ensure global serializability under this assumption, the level of concurrency may be such that other schemes, such as the two-level serializability technique discussed in Section 2461, are attractive alternatives

247 Summary

Work ows are activities that involve the coordinated execution of multiple tasks performed by different processing entities They exist not just in computer applications, but also in almost all organizational activities With the growth of networks, and the existence of multiple autonomous database systems, work ows provide a convenient way of carrying out tasks that involve multiple systems Although the usual ACID transactional requirements are too strong or are unimplementable for such work ow applications, work ows must satisfy a limited set of transactional properties that guarantee that a process is not left in an inconsistent state Transaction-processing monitors were initially developed as multithreaded servers that could service large numbers of terminals from a single process They have since evolved, and today they provide the infrastructure for building and administering complex transaction-processing systems that have a large number of clients and multiple servers They provide services such as durable queueing of client requests and server responses, routing of client messages to servers, persistent messaging, load balancing, and coordination of two-phase commit when transactions access multiple servers Large main memories are exploited in certain systems to achieve high system throughput In such systems, logging is a bottleneck Under the group-commit concept, the number of outputs to stable storage can be reduced, thus releasing this bottleneck The ef cient management of long-duration interactive transactions is more complex, because of the long-duration waits, and because of the possibility of aborts Since the concurrency-control techniques used in 16 use waits, aborts, or both, alternative techniques must be considered These techniques must ensure correctness without requiring serializability A long-duration transaction is represented as a nested transaction with atomic database operations at the lowest level If a transaction fails, only active shortduration transactions abort Active long-duration transactions resume once