1. Middleware based Data Replication providing Snapshot Isolation Yi Lin Bettina Kemme Marta Patiño-Martínez Ricardo Jiménez-Peris June 15, 2005

2. Data Replication: What,Why,How? …… Without ReplicationWith Replication Problem: Scalability, Fault Tolerance Challenge: Keep copies consistent

3. Data Replication: challenge w(x) General correctness criteria: 1-copy-serializability x x x x x x Replica control Our new criteria: 1-copy-snapshot isolation Replica + Concurrency Control Keep copies consistent Isolate concurrent transactions

4. Kernel-based approach Middleware-based approach –Advantages Modular Do not need access to DB code Reusability –Disadvantages No access to concurrency control information in the kernel Implementing Replica Control

5. Some provide table-based concurrency control [Middle-R, Conflict Aware, C-JDBC] Some are primary/secondary approaches. [Ganymed] –Updates must always be performed on primary copy Nearly all only look at 1-copy- serializability [Conflict Aware, GlobData, Middle-R, C-JDBC, State Machine] primarysecondary Related Work

6. Concurrency Control: serializability Serializability –Highest transaction isolation level to what extend transactions interfere with each other –The result is the same as executing them serially. –Conflict: read/write and write/write time T0 T1 T2 w(x) r(x) w(x) w(y) w(x) r(x)w(y) r(x),w(x) time T0 T1 T2

7. Snapshot Isolation (SI): –Conflict: only write/write –Read from a snapshot of the committed data as of the time the transaction starts. –First committer wins: of 2 concurrent conflicting write transactions, one commits, the other aborts –Similarity with optimistic concurrency control –Very popular (Oracle, PostgreSQL, SQL Server 2005) time T0 T1 T2 w(x) r(x) w(x) w(y) commit abort Concurrency Control: Snapshot Isolation

8. Remainder of the Talk Define 1-copy-SI Protocols –Centralized middleware –Decentralized middleware Evaluation Conclusions

9. Our new correctness criteria: 1-copy-SI 1-copy-SI: The replicated system behaves as one database providing SI. –Each DB provides SI. –All read operations read from snapshots producible in one DB …... SI == x x x 1-copy-SI SI

10. Challenge: How to detect concurrent conflicting txns?  Validation A Centralized Replica Control Protocol w(x) validation commit succeedfail Get writeset r(x) x x x x x x x x apply writeset, commit T2T1 JDBC

11. How to detect two transactions are conflicting? –Writeset contains modified tuples and their corresponding primary keys. –If two writesets share some primary keys, they conflict. –Note: Snapshot Isolation only cares about write/write conflicts. Key=1T1T2 A Centralized Replica Control Protocol

12. How to detect two transactions are concurrent? T1 T2 start=1 A counter for each database, increased upon committing a transaction Record start time and end time of transactions T0.end  T1.start || T1.end  T0.start  T0 and T1 not concurrent. T0 start=0end=1 end=2 counter start=1 A Centralized Replica Control Protocol

13. r3(x,y),c3 r4(x,y),c4 xyxy x w2(y),c2w1(x),c1 y w2(y),c2 y x 1-copy-SI more than just keeping data consistent T1:w1(x), val. succeed T2:w2(y), val. succeed

14. r3(x,y),c3r4(x,y),c4 w2(y),c2 w1(x),c1 1-copy-SI solution 1 T1:w1(x), val. succeed T2:w2(y), val. succeed xy xy xy x y y x Deadlock when working with real DBs: spanning across the middleware and DB

15. 1-copy-SI: solution 2 r3(x,y),c3 r4(x,y),c4 x w2(y),c2 w1(x),c1 y w2(y),c2 y x r4(x,y),c4 T1:w1(x), val. succeed T2:w2(y), val. succeed xy xyxy xy

16. Group Comm, Total order multicast Decentralized SIR Protocol x x r(x) commit w(x) Extract writeset T1 T2 T1 T2 validation Summary: 1.Validation  same as centralized approach 2.Total order multicast  all middleware components make the same decision fail succeed apply ws, commit x x abort JDBC

17. Experiment 5 sites, 100% update transactions, Decentralized No Replication Table-based locking

18. Conclusions Definition of 1-Copy-SI Middleware based Replication Protocols providing 1-Copy-SI Replication transparent to clients –Connect via JDBC and submit operations as if non-replicated system Tuple based concurrency control

19. References 1.[Conflict-Aware] C. Amza, A. L. Cox, and W. Zwaenepoel. Conict-Aware Scheduling for Dynamic Content Applications. In USENIX Symp. on Internet Tech. and Sys., 2003. 2.[C-JDBC] E. Cecchet, J. Marguerite, and W. Zwaenepoel. C-JDBC: Flexible database clustering middlerware, USENIX 2004 3.[Ganymed] C. Plattner and G. Alonso. Ganymed: Scalable replication for transactional web applications. In Middleware, 2004. 4.[GlobData] L. Rodrigues, H. Miranda, R. Almeida, J. Martins, and P. Vicente. Strong Replication in the GlobData Middleware. In Workshop on Dependable Middleware-Based Systems, 2002. 5.[Middle-R] R. Jiménez-Peris, M. Patiño-Martínez, B. Kemme, and G. Alonso. Improving Scalability of Fault Tolerant Database Clusters. In ICDCS'02. 6.[Postgres-R] S. Wu and B. Kemme. Postges-R(SI): Combining replica control with concurrency control based on snapshot isolation. In ICDE, Tokoyo, Japan, 2005. 7.[State Machine] F. Pedone, R. Guerraoui, and A. Schiper. The Database State Machine Approach. Distributed and Parallel Databases, 14:71-98, 2003.

20. Writeset Containing modified tuples and their primary keys Implemented by triggers or log sniffing Currently not provided by DB standard interfaces –PostgreSQL is currently implementing such interface