1 / 14

Replicating Basic Components

Replicating Basic Components. Bettina Kemme McGill University, Montreal, Canada. Outline. Previous Work: Database replication Interest Resources Current related work. Group Communication and Replica Control. T’. T. T. T’. T’. T. GC provide delivery guarantees. Avoid 2PC. DB.

Download Presentation

Replicating Basic Components

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Replicating Basic Components Bettina Kemme McGill University, Montreal, Canada

  2. Outline • Previous Work: Database replication • Interest • Resources • Current related work

  3. Group Communication and Replica Control T’ T T T’ T’ T GC provide • delivery guarantees Avoid 2PC DB Group Comm. DB GC provide • total order multicast Serialize transactions according to total order

  4. Embedded Architecture T’ T’ T T DB DB Repl. Tool Repl. Tool GC GC

  5. Implemented Features • A client connects to one site • But this can be any site in the system • Enhanced concurrency protocol guarantees serializability • Execution Model • Communication at the END of the transaction once all update operations are determined • reexecute updates at other sites • Only apply changes at remote sites • Failure doesn’t stop other sites • Only clients connected to failed site must reconnect • Semantic for these clients as usual: an unanswered commit request might have succeeded or not

  6. Implemented Features • Online recovery • One site transfers state to recovering site • Other sites continue execution • Simple transfer scheme (entire database) • Only basic handling in case new failure occurs during online recovery • Partial Replication • Requests send to all • Filtering at receiving sites • Automatic redirecting of queries that cannot be answered locally

  7. Developed Features • Online recovery • Minimizing state transfer costs • Advanced handling of failures during reconfiguration • Exactly-once transactions in failure-recovery model: • When a transaction commits at a site shortly before failing, the transaction should commit at the available sites • When a site recovers, for a given transaction: • The result of the transaction is already in the DB of the recovering site • It receives the results within the state transfer • It receives the transaction after finishing the transfer • Current work with Alberto: • Only GC is not enough because transactions commits some time after message is delivered -- failure in between possible

  8. Middleware Architecture T’ T’ T’ T’ T T T T Replication Tool Replication Tool GC GC DB DB

  9. Implemented Features • Client currently part of the group • Message is forwarded at BOT • Concurrency control in middleware layer at BOT • One site executes transaction • Message with changes at EOT • Failure Model • Execution guarantee once the first message made it • Concept usable for ADAPT middleware layer?

  10. Developed Features • Optimistic Execution: • Overlap communication overhead and transaction processing • Might be of interest in WAN

  11. Main Interests • In basic services • All components: • Communication -- working with Alberto and Ozalp • Transactional • More complex transactional models in basic components (J2EE is flat -- how do we want to extend?) • Replication of stateful services • In middleware architecture • Intra-organizational and inter-organizational

  12. Resources Available • Funding: • General funding situation regarding IST-project • Funding for PhD student guaranteed for the entire period • Technical assistance: likely to be funded • Hardware/Software is secured • Travel

  13. Resources Available • Current situation • PhD student started on topic in July • Implemented TPC-W on top of JBoss in order to learn J2EE • Starts to have reasonable background in transactions/replication/fault-tolerance/group-communication/object management • Master students work on related topics • Hardware/Software • Lab more or less established • New infrastructure will be installed within the next year

  14. Related Work • Current situation Postgres-R • One master student works on it • Currently: Migration to PostgreSQL 7.2 • Open Source Involvement • See Gborg web-page on replication • Company funding • “Basic Components for Bioinformatics” • Web-based/application server infrastructure • Access control

More Related