DOCSLIB.ORG

Transactions in Federated Databases

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Transactions in Federated Databases Chapter 10: Transactions in Federated Databases Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 1 Topic of this Chapter Serializability in distributed systems (i.e., isolation). Several tansactions. Introduction One solution has already been proposed Strictness (see next slide). COCSR In this chapter, we look at one specific case Tickets (federated databases) where that solution is insufficient. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 2 – Folie aus vergangenem Kapitel – Data is partitioned among nodes. Distributed Locking Each node synchronizes operations that access data on its partition. No further communication (except for replicas): distributed execution of transactions and operations already adapted to distribution of data. Release of locks with strict 2PL as part of ACP. Biggest problem: global deadlocks. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 3 Global Transaction Management Works, but may be too optimistic. Global TM may synchronize global transactions. Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 4 Federated Databases Introduction Strictness COCSR Tickets Sales R&D Human Resources Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 5 Transaction Managmement in Federated DBMSs (1) Global Introduction Transactions Strictness COCSR Global Tickets TM Local TMs Local Transactions Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 6 Transaction Managmement in Federated DBMSs (2) Common assumption: all transactions under control of a global distributed transaction manager (TM). Introduction Now: local transactions Strictness COCSR unknown to the GTM in addition. Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 7 Transaction Managmement in Federated DBMSs (2) How to achieve global serializability? Introduction Is the following sufficient? Strictness Same concurrency-control protocol, and COCSR each server guarantees local serializability? Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 8 Example (1) D1={a}; D 2={b, c}, global transactions T1=r(a) w(b); T 2= r(c) w(a), Introduction local transactions T3=r(b) w(c). Strictness Why are T1 and T 2 global, and T3 is local? COCSR Tickets Global TM is ‚conservative‘; serial execution (T1; T 2). Possible local histories: server 1: s 1= r 1(a) w2(a) server 2: s 2= r3(b) w 1(b) r 2(c) w 3(c) What are the local serialization orders? Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 9 Example (2) Corresponding global history: s= r 1(a) r 3(b) w 1(b) r 2(c) w 2(a) w 3(c) ≈ ≈ Introduction s1, s 2 conflict-serializable: s 1 cT1T2; s 2 cT2T3T1 Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 10 Direct vs. Indirect Conflict Important distinction: direct conflict vs. indirect conflict . Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 11 Global Serializability – Overview Global serializability based on local guarantees. 1. Strictness, and commit is delayed , Introduction Strictness 2. commitment ordering. COCSR Tickets Tickets (do not require additional local guarantees; ticket ≡ additional local database object that global transactions must manipulate) Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 12 Strictness (1) strictness := write(x, val) is delayed until all transactions that have written x before Introduction have committed or aborted, Strictness COCSR + cascadelessness. Tickets Cascadelessness := Each transaction only reads values of committed transactions. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 13 Strictness (2) T1 = w 1[x] w 1[y] w 1[z] c 1 T2 = r 2[u] w 2[x] r 2[y] w 2[y] c 2 Introduction Strictness H9 = w 1[x] w 1[y] r 2[u] w 2[x] w 1[z] c 1 r2[y] w 2[y] c 2 COCSR Tickets H10 = w 1[x] w 1[y] r 2[u] w 1[z] c 1 w2[x] r 2[y] w 2[y] c 2 Which histories are strict? Which ones are cascadeless? Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 14 Strictness (3) Strictness alone does not suffice to ensure global serializability. Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 15 Strictness (4) Strictness alone does not suffice to ensure global serializability – example: D ={a,b}; D ={c,d}, Introduction 1 2 Strictness global transactions: T 1=w(a) w(d), T 2=w(c) w(b), COCSR local transactions: T = r(a) r(b), T = r(c) r(d), Tickets 3 4 local histories: s1= w 1(a) c 1 r3(a) r 3(b) c 3 w2(b) c 2 s2= w 2(c) c 2 r4(c) r 4(d) c 4 w1(d) c 1 s1 and s 2 are strict, but serialization orders differ. Observe that order of commits of global transactions differs between nodes. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 16 Strictness (5) Do not issue commit right away. Global transaction is commit-deferred := global TM sends commit to local sites Introduction Strictness only after the local sites have acknowledged COCSR execution of all operations. Tickets Global Transactions Global TM Local TMs Local Transactions Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 17 Strictness (6) Continuation of example: D1={a,b}; D 2={c,d} Introduction global transactions: Strictness T1= w(a) w(d), T 2= w(c) w(b) COCSR local transactions: T = r(a) r(b), T = r(c) r(d) Tickets 3 4 local histories: – s1= w 1(a) c 1 r3(a) r 3(b) c 3 w2(b) c 2 – s2= w 2(c) c 2 r4(c) r 4(d) c 4 w1(d) c 1 Not allowed. Deadlock situation. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 18 Strictness (7) Continuation of example: D1={a,b}; D 2={c,d} global transactions: T = w(a) w(d), T = w(c) w(b) Introduction 1 2 Strictness local transactions: T 3= r(a) r(b), T 4= r(c) r(d) COCSR local histories: Tickets – s1= w 1(a) c 1 r3(a) r 3(b) c 3 w2(b) c 2 – s2= w 2(c) c 2 r4(c) r 4(d) c 4 w1(d) c 1 c2 takes place strictly after c1 in s 1: – r3(a) after c 1 because of strictness. – w2(b) after r 3(b) according to serialization order. – c2 after w 2(b) because of commit-deferredness. Analogously, c1 takes place strictly after c2. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 19 Strictness (8) Theorem: let s be a global history for s1, ..., sn. ≤ ≤ si is strict for 1 i n, and all global transactions are commit-deferred. Introduction ⇒ s is globally serializable. Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 20 Strictness (9) Why is commit-deferredness, together with local serializability, not sufficient? Why do we need strictness as well? Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 21 Strictness (10) Running example: D1={a,b}; D 2={c,d} global transactions: T 1= w(a) w(d), T 2= w(c) w(b) Introduction Strictness local transactions: T 3= r(a) r(b), T 4= r(c) r(d) COCSR Global TM issues w1(a) and w 1(d). Tickets Then w2(c) and w 2(b). No guarantee that operations take place in that order. (At least when global TM does without handshaking.) Thus, local histories so far could be: – s1= w 1(a) r3(a) r 3(b) c 3 w2(b) – s2= w 2(c) r 4(c) r 4(d) c 4 w1(d) Global TM now issues c1, on both nodes. z Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 22 Commitment Ordering (1) Global serializability based on local guarantees. Approach 2: commitment ordering (COCSR). Introduction Commit order conflict serializability := Strictness Two transactions conflict. COCSR ⇒ Commit operations in conflict order. Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 23 Commitment Ordering (2) A DBMS that implements commitment ordering works as follows – example: applications issue w (x), w (x), c , Introduction 1 2 2 Strictness stricly after each other (handshaking). COCSR Now c1 is submitted to the DBMS – Tickets DBMS must reject it, must abort T1. Execution order w 1(x) w 2(x) c 2 c1 does not have commit operations in conflict order. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 24 Commitment Ordering (3) COCSR, and commits of global transactions are executed one after the other („handshaking“). ⇒ History is globally serializable. Introduction Strictness COCSR Tickets Global Transactions Global TM Local TMs Local Transactions Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 25 Commitment Ordering (4) Example – two histories: s1= r1(a) c 1 w3(a) w 3(b) c 3 r2(b) c 2 Introduction s2= w 4(c) r1(c) r2(d) r4(e) c1 c2 [w 4(d) c 4] Strictness COCSR Tickets Observe that s2 is not COCSR. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 26 Commitment Ordering (5) Example – two histories: s1= r1(a) c 1 w3(a) w 3(b) c 3 r2(b) c 2 Introduction s2= w 4(c) r1(c) r2(d) r4(e) c1 c2 [w 4(d) c 4] Strictness COCSR Tickets Observe that s2 is not COCSR. Why is COCSR alone not sufficient? Suppose c1 and c 2 are issued in parallel; c1 is delayed. This may result in commit order c 2 c4 c1. I.e., COCSR on both sites, but no local serializability. z Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 27 Tickets (1) In what follows: nodes do not offer additional properties such as strictness or COCSR, only CSR locally.
Load more

Recommended publications
  • Let's Talk About Storage & Recovery Methods for Non-Volatile Memory
    Let’s Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems Joy Arulraj Andrew Pavlo Subramanya R. Dulloor [email protected] [email protected] [email protected] Carnegie Mellon University Carnegie Mellon University Intel Labs ABSTRACT of power, the DBMS must write that data to a non-volatile device, The advent of non-volatile memory (NVM) will fundamentally such as a SSD or HDD. Such devices only support slow, bulk data change the dichotomy between memory and durable storage in transfers as blocks. Contrast this with volatile DRAM, where a database management systems (DBMSs). These new NVM devices DBMS can quickly read and write a single byte from these devices, are almost as fast as DRAM, but all writes to it are potentially but all data is lost once power is lost. persistent even after power loss. Existing DBMSs are unable to take In addition, there are inherent physical limitations that prevent full advantage of this technology because their internal architectures DRAM from scaling to capacities beyond today’s levels [46]. Using are predicated on the assumption that memory is volatile. With a large amount of DRAM also consumes a lot of energy since it NVM, many of the components of legacy DBMSs are unnecessary requires periodic refreshing to preserve data even if it is not actively and will degrade the performance of data intensive applications. used. Studies have shown that DRAM consumes about 40% of the To better understand these issues, we implemented three engines overall power consumed by a server [42]. in a modular DBMS testbed that are based on different storage Although flash-based SSDs have better storage capacities and use management architectures: (1) in-place updates, (2) copy-on-write less energy than DRAM, they have other issues that make them less updates, and (3) log-structured updates.
    [Show full text]
  • Failures in DBMS
    Chapter 11 Database Recovery 1 Failures in DBMS Two common kinds of failures StSystem filfailure (t)(e.g. power outage) ‒ affects all transactions currently in progress but does not physically damage the data (soft crash) Media failures (e.g. Head crash on the disk) ‒ damagg()e to the database (hard crash) ‒ need backup data Recoveryyp scheme responsible for handling failures and restoring database to consistent state 2 Recovery Recovering the database itself Recovery algorithm has two parts ‒ Actions taken during normal operation to ensure system can recover from failure (e.g., backup, log file) ‒ Actions taken after a failure to restore database to consistent state We will discuss (briefly) ‒ Transactions/Transaction recovery ‒ System Recovery 3 Transactions A database is updated by processing transactions that result in changes to one or more records. A user’s program may carry out many operations on the data retrieved from the database, but the DBMS is only concerned with data read/written from/to the database. The DBMS’s abstract view of a user program is a sequence of transactions (reads and writes). To understand database recovery, we must first understand the concept of transaction integrity. 4 Transactions A transaction is considered a logical unit of work ‒ START Statement: BEGIN TRANSACTION ‒ END Statement: COMMIT ‒ Execution errors: ROLLBACK Assume we want to transfer $100 from one bank (A) account to another (B): UPDATE Account_A SET Balance= Balance -100; UPDATE Account_B SET Balance= Balance +100; We want these two operations to appear as a single atomic action 5 Transactions We want these two operations to appear as a single atomic action ‒ To avoid inconsistent states of the database in-between the two updates ‒ And obviously we cannot allow the first UPDATE to be executed and the second not or vice versa.
    [Show full text]
  • An Efficient Concurrency Control Technique for Mobile Database Environment by Md
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Global Journal of Computer Science and Technology (GJCST) Global Journal of Computer Science and Technology Software & Data Engineering Volume 13 Issue 2 Version 1.0 Year 2013 Type: Double Blind Peer Reviewed International Research Journal Publisher: Global Journals Inc. (USA) Online ISSN: 0975-4172 & Print ISSN: 0975-4350 An Efficient Concurrency Control Technique for Mobile Database Environment By Md. Anisur Rahman Dhaka University of Engineering & Technology Gazipur, Bangladesh Abstract - Day by day, wireless networking technology and mobile computing devices are becoming more popular for their mobility as well as great functionality. Now it is an extremely growing demand to process mobile transactions in mobile databases that allow mobile users to access and operate data anytime and anywhere, irrespective of their physical positions. Information is shared among multiple clients and can be modified by each client independently. However, for the assurance of timely access and correct results in concurrent mobile transactions, concurrency control techniques (CCT) happen to be very difficult. Due to the properties of Mobile databases e.g. inadequate bandwidth, small processing capability, unreliable communication, mobility etc. existing mobile database CCTs cannot employ effectively. With the client-server model, applying common classic pessimistic techniques of concurrency control (like 2PL) in mobile database leads to long duration Blocking and increasing waiting time of transactions. Because of high rate of aborting transactions, optimistic techniques aren`t appropriate in mobile database as well. This paper discusses the issues that need to be addressed when designing a CCT technique for Mobile databases, analyses the existing scheme of CCT and justify their performance limitations.
    [Show full text]
  • ACID Compliant Distributed Key-Value Store
    ACID Compliant Distributed Key-Value Store #1 #2 #3 Lakshmi Narasimhan Seshan ,​ Rajesh Jalisatgi ,​ Vijaeendra Simha G A # ​ ​ ​ ​1l​ [email protected] # ​2r​ [email protected] #3v​ [email protected] Abstract thought that would be easier to implement. All Built a fault-tolerant and strongly-consistent key/value storage components run http and grpc endpoints. Http endpoints service using the existing RAFT implementation. Add ACID are for debugging/configuration. Grpc Endpoints are transaction capability to the service using a 2PC variant. Build used for communication between components. on the raftexample[1] (available as part of etcd) to add atomic Replica Manager (RM): RM is the service discovery transactions. This supports sharding of keys and concurrent transactions on sharded KV Store. By Implementing a part of the system. RM is initiated with each of the transactional distributed KV store, we gain working knowledge Replica Servers available in the system. Users have to of different protocols and complexities to make it work together. instantiate the RM with the number of shards that the user wants the key to be split into. Currently we cannot Keywords— ACID, Key-Value, 2PC, sharding, 2PL Transaction dynamically change while RM is running. New Replica ​ ​ Servers cannot be added or removed from once RM is I. INTRODUCTION ​ up and running. However Replica Servers can go down Distributed KV stores have become a norm with the and come back and RM can detect this. Each Shard advent of microservices architecture and the NoSql Leader updates the information to RM, while the DTM revolution. Initially KV Store discarded ACID properties leader updates its information to the RM.
    [Show full text]
  • Lecture 15: March 28 15.1 Overview 15.2 Transactions
    CMPSCI 677 Distributed and Operating Systems Spring 2019 Lecture 15: March 28 Lecturer: Prashant Shenoy 15.1 Overview This section covers the following topics: Distributed Transactions: ACID Properties, Concurrency Control, Serializability, Two-Phase Locking 15.2 Transactions Transactions are used widely in databases as they provide atomicity (all or nothing property). Atomicity is the property in which operations inside a transaction all execute successfully or none of the operations execute. Thus, if a process crashes during a transaction, all operations that happened during that transaction must be undone. Transactions are usually implemented using locks. Without locks there would be interleaving of operations from two transactions, causing overwrites and inconsistencies. It has to look like all instructions/operations of one transaction are executed at once, while ensuring other external instructions/operations are not executing at the same time. This is especially important in real-world applications such as banking applications. 15.2.1 ACID: Most transaction systems will provide the following properties • Atomicity: All or nothing (all instructions execute or none; cannot have some instructions execute and some do not) • Consistency: Transaction takes system from one consistent (valid) state to another • Isolated: Transaction executes as if it is the only transaction in the system. Ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed sequentially (serializability).
    [Show full text]
  • A View-Based Approach to Relaxing Global Serializability in Multidatabase Systems
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1993 A View-Based Approach to Relaxing Global Serializability in Multidatabase Systems Aidong Zhang Evaggelia Pitoura Bharat K. Bhargava Purdue University, [email protected] Report Number: 93-082 Zhang, Aidong; Pitoura, Evaggelia; and Bhargava, Bharat K., "A View-Based Approach to Relaxing Global Serializability in Multidatabase Systems" (1993). Department of Computer Science Technical Reports. Paper 1095. https://docs.lib.purdue.edu/cstech/1095 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. A VIEW-BASED APPROACH TO RELAXING GLOBAL SERIALIZABILITY IN MULTIDATABASE SYSTEMS Aldong Zhang Evaggelia PitOUI'3 Bharat Bh:Jrgava CSD TR-9J.082 December 1993 (Revised March 1994) A View-Based Approach to Relaxing Global Serializability in Multidatabase Systems Aidong Zhang, Evaggelia Pitoura, and Bharat K Bhargava Department of Computer Science Purdue University West Lafayette, IN 47907 USA Abstract In this paper, we propose a new approach to ensuring the correctness of non­ serializable executions. The approach is based on relating transaction views of the database to the integrity constraints of the system. Drawing upon this approach, we de­ velop a new correctness criterion for multidatabase concurrency control. This criterion, caUed view-based two-level serializability, relaxes global serializabitity in multidatabase systems while respecting the autonomy of local database systems. No additional re­ strictions other than serializallility are imposed on local database systems. 1 Introduction A Illultidataba.-<;e system (MDBS) is a higher-level confederation of a nWllber of pre-existing autonomolls and possibly heterogeneous database systems.
    [Show full text]
  • What Is Nosql? the Only Thing That All Nosql Solutions Providers Generally Agree on Is That the Term “Nosql” Isn’T Perfect, but It Is Catchy
    NoSQL GREG SYSADMINBURD Greg Burd is a Developer Choosing between databases used to boil down to examining the differences Advocate for Basho between the available commercial and open source relational databases . The term Technologies, makers of Riak. “database” had become synonymous with SQL, and for a while not much else came Before Basho, Greg spent close to being a viable solution for data storage . But recently there has been a shift nearly ten years as the product manager for in the database landscape . When considering options for data storage, there is a Berkeley DB at Sleepycat Software and then new game in town: NoSQL databases . In this article I’ll introduce this new cat- at Oracle. Previously, Greg worked for NeXT egory of databases, examine where they came from and what they are good for, and Computer, Sun Microsystems, and KnowNow. help you understand whether you, too, should be considering a NoSQL solution in Greg has long been an avid supporter of open place of, or in addition to, your RDBMS database . source software. [email protected] What Is NoSQL? The only thing that all NoSQL solutions providers generally agree on is that the term “NoSQL” isn’t perfect, but it is catchy . Most agree that the “no” stands for “not only”—an admission that the goal is not to reject SQL but, rather, to compensate for the technical limitations shared by the majority of relational database implemen- tations . In fact, NoSQL is more a rejection of a particular software and hardware architecture for databases than of any single technology, language, or product .
    [Show full text]
  • Oracle Nosql Database
    An Oracle White Paper November 2012 Oracle NoSQL Database Oracle NoSQL Database Table of Contents Introduction ........................................................................................ 2 Technical Overview ............................................................................ 4 Data Model ..................................................................................... 4 API ................................................................................................. 5 Create, Remove, Update, and Delete..................................................... 5 Iteration ................................................................................................... 6 Bulk Operation API ................................................................................. 7 Administration .................................................................................... 7 Architecture ........................................................................................ 8 Implementation ................................................................................... 9 Storage Nodes ............................................................................... 9 Client Driver ................................................................................. 10 Performance ..................................................................................... 11 Conclusion ....................................................................................... 12 1 Oracle NoSQL Database Introduction NoSQL databases
    [Show full text]
  • Concurrency Control Basics
    Outline l Introduction/problems, l definitions Introduction/ (transaction, history, conflict, equivalence, Problems serializability, ...), Definitions l locking. Chapter 2: Locking Concurrency Control Basics Klemens Böhm Distributed Data Management: Concurrency Control Basics – 1 Klemens Böhm Distributed Data Management: Concurrency Control Basics – 2 Atomicity, Isolation Synchronisation, Distributed (1) l Transactional guarantees – l Essential feature of databases: in particular, atomicity and isolation. Many users can access the same data concurrently – be it read, be it write. Introduction/ l Atomicity Introduction/ Problems Problems u Example, „bank scenario“: l Consistency must be guaranteed – Definitions Definitions task of synchronization component. Locking Number Person Balance Locking Klemens 5000 l Multi-user mode shall be hidden from users as far as possible: concurrent processing Gunter 200 of requests shall be transparent, u Money transfer – two elementary operations. ‚illusion‘ of being the only user. – debit(Klemens, 500), – credit(Gunter, 500). l Isolation – can be explained with this example, too. l Transactions. Klemens Böhm Distributed Data Management: Concurrency Control Basics – 3 Klemens Böhm Distributed Data Management: Concurrency Control Basics – 4 Synchronisation, Distributed (2) Synchronization in General l Serial execution of application programs Uncontrolled non-serial execution u achieves that illusion leads to other problems, notably inconsistency: l Introduction/ without any synchronization effort, Introduction/
    [Show full text]
  • The Integration of Database Systems
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1993 The Integration of Database Systems Tony Schaller Omran A. Bukhres Ahmed K. Elmagarmid Purdue University, [email protected] Xiangning Liu Report Number: 93-046 Schaller, Tony; Bukhres, Omran A.; Elmagarmid, Ahmed K.; and Liu, Xiangning, "The Integration of Database Systems" (1993). Department of Computer Science Technical Reports. Paper 1061. https://docs.lib.purdue.edu/cstech/1061 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. The Integration of Database Systems Tony Schaller, Omran A. Bukhres, Ahmed K. Elmagarmid and Xiangning Liu CSD-TR-93-046 July 1993 I I The Integration of Database Systems Tony Schaller Molecular Design Ltd. 2132 Farallon Drive San Leandro, CA 94577 Omran A. Bukhres, Ahmed K. Elmagarmid and Xiangning Liu DeparLment of Computer Sciences Purdue University West Lafayette, IN 47907 eJIlail: {bukhres,ake,xl} .es.purdue.edu 1 Introduction A database system is composed of two elements: a software program, called a database management system, and a set of data, called a database. The data in a database is organized according to some data model, such as the relational model used in a DB2 database [DW88] or the hierarchical model found with IMS databases [Dat77] . Users access the data through an interface (the query language) provided by the database management system. A schema describes the actual data structures and organization within the system. During the decade ofthe nineteen-seventies, centralized databases were predominant, but recent innovations in communications and database technologies have engendered a revolution in data processing, giving rlse to a new generation of decentralized database systems.
    [Show full text]
  • Distributed Transactions
    Distributed Systems 600.437 Distributed Transactions Department of Computer Science The Johns Hopkins University Yair Amir Fall 16/ Lecture 6 1 Distributed Transactions Lecture 6 Further reading: Concurrency Control and Recovery in Database Systems P. A. Bernstein, V. Hadzilacos, and N. Goodman, Addison Wesley. 1987. Transaction Processing: Concepts and Techniques Jim Gray & Andreas Reuter, Morgan Kaufmann Publishers, 1993. Yair Amir Fall 16/ Lecture 6 2 Transaction Processing System Clients Messages to TPS outside world Real actions (firing a missile) Database Yair Amir Fall 16/ Lecture 6 3 Basic Definition Transaction - a collection of operations on the physical and abstract application state, with the following properties: • Atomicity. • Consistency. • Isolation. • Durability. The ACID properties of a transaction. Yair Amir Fall 16/ Lecture 6 4 Atomicity Changes to the state are atomic: - A jump from the initial state to the result state without any observable intermediate state. - All or nothing ( Commit / Abort ) semantics. - Changes include: - Database changes. - Messages to outside world. - Actions on transducers. (testable / untestable) Yair Amir Fall 16/ Lecture 6 5 Consistency - The transaction is a correct transformation of the state. This means that the transaction is a correct program. Yair Amir Fall 16/ Lecture 6 6 Isolation Even though transactions execute concurrently, it appears to the outside observer as if they execute in some serial order. Isolation is required to guarantee consistent input, which is needed for a consistent program to provide consistent output. Yair Amir Fall 16/ Lecture 6 7 Durability - Once a transaction completes successfully (commits), its changes to the state survive failures (what is the failure model ? ).
    [Show full text]
  • Effective Technique for Optimizing Timestamp Ordering in Read- Write/Write-Write Operations
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 06 Issue: 09 | Sep 2019 www.irjet.net p-ISSN: 2395-0072 Effective Technique for Optimizing Timestamp Ordering in Read- Write/Write-Write Operations Obi, Uchenna M1, Nwokorie, Euphemia C2, Enwerem, Udochukwu C3, Iwuchukwu, Vitalis C4 1Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 2Senior Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 3Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 4Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria ---------------------------------------------------------------------***---------------------------------------------------------------------- Abstract - In recent times, the use of big data has been the measures, these are: read-write (RW) synchronization and trending technology, most enterprises tend to adopt large write-write (WW) synchronization. databases, but the inherent problem is how to ensure serializability in concurrent transactions that may want to Concurrency control techniques are employed for managing access the data in the database so as to maintain its data concurrent access of transactions on a particular data item integrity and not to compromise it. The aim of this research is by ensuring serializable executions or to avoid interference to develop an efficient Timestamp Ordering algorithm and among transactions and thereby helps in avoiding errors and model in conflicting operations in read-write/write-write data maintain consistency of the database. Various concurrency synchronization. In read-write synchronization, one of the control techniques have been developed by different operations to perform is read while the other is write researchers and these techniques are distinct and unique in operation.
    [Show full text]