1. EJB Replication Graham, Iman, Santosh, Mark Newcastle University

2. Aims Investigate how software implemented fault tolerance techniques can be applied to support component replication for high availability. We take the specific case of EJB components and consider strict consistency (that requires that the states of all available copies of replicas be kept mutually consistent). –Components that are transparently using persistence and transactions can also be made highly available, enabling a transaction involving EJBs to commit despite a finite number of failures. –Ensure that our approach requires minimal alterations to application server, container, EJB and data store.

3. Approaches (i) State replication with single application server: Database is replicated; (ii) State replication with clustered application servers: Database is replicated; (iii) State and computation replication with clustered application servers: Database is replicated and instances of beans are replicated on a cluster of application servers;

4. Transaction involving multiple beans

5. (i) State replication with single application server: Database is replicated

6. (ii) State replication with clustered application servers: Database is replicated

7. (iii) State and computation replication with clustered application servers Requirement: –Ensure states of EJBs in container replicas and transactional states within respective transaction managers are mutually consistent. Issues: –Active scheme – multi-threaded implementation of homogeneous and/or heterogeneous application server environment results in non-determinism. –Passive – theoretically possible via the checkpoint of container state in homogeneous application server environment. Much more challenging in heterogeneous environment (implementation is vender dependent and often hidden). –Transaction manager – no standard for initialising transaction manager from checkpointed log.

8. Implementing state and computation replication with clustered application servers Approach –Snapshot of container (possibly application server) state to be taken such that another container/server could take this snapshot and reconstitute the environment at the point snapshot was originally taken. Requirement –Standard interfaces allowing development and deployment of state transfer mechanisms across J2EE environments. Enabling technology – J2EE APIs for Continuous Availability, in particular, the notion of Field Replaceable Unit (FRU). –An FRU is a collection of modules that may be part of (for example) an application server. The definer of an FRU is responsible for ensuring state transfer between implementations is possible. Very early stages of development.

9. Conclusions Proposed solution for replication of data stores without alteration to either data store or application server code. –Mechanism required to enable data store replication restricted to resource adaptor (proxy). Integration of transactions and data store replication achieved. –Group communication subsystem required for agreement (failures, primary). Issues regarding state and computational replication highlighted. –Difficult engineering problems to solve.