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

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

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

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

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

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

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

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

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

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

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

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

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

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