Determining the relative execution frequency of program regions is essential for many important optimization techniques, including register allocation,

Abstract. Replication has been widely used in J2EE servers for reliability and scalability. There are two properties which are important for a stateful J2EE application server. Firstly, the state of the server and the state of the backend databases should always be consistent. Secondly, each request from a client should be executed exactly once. In this paper, we propose a replication algorithm that provides both properties. We use passive replication where a primary server executes a request, and all state changed within the application server by this request is sent to the backup replicas at the end of the execution. An agreement protocol guarantees the consistency between the state of all replicas and the database. A client side communication stub automatically resubmits requests in case of failures, and unnecessary resubmissions are detected by the server replicas. We have implemented the algorithm and integrated it into the JBoss application server. A performance study using the ECPerf benchmark shows the feasibility of our approach.

Determining the relative execution frequency of program regions is essential for many important optimization techniques, including register allocation, function inlining, and instruction scheduling. Estechniques, we identify 76% of the most frequently executed call sites.

In application server systems, such as J2EE, replication is an essential strategy for reliability and efficiency. Many J2EE implementations, both commercial and open-source, provide some replication support. However, the range of possible strategies is wide, and the choice of the best one, depending on the expected application profile, remains an open research question. To support research in this area, we introduce a framework for prototyping J2EE replication algorithms. In effect, it divides replication code into two layers: the framework itself, which is common to all replication algorithms, and a specific replication algorithm, which is "plugged in" to the framework. The division is defined by an API. The framework simplifies development in two ways. First, it keeps much of the complexity of modifying a J2EE implementation within the framework layer, which is implemented only once. Second, through the API, the replication algorithm sees a highly abstracted view of the components in the server. This frees the designer to concentrate on the important issues that are specific to a replication algorithm, such as communication. We have implemented the framework by extending the open-source J2EE server. Compared to an unmodified server, the framework adds a performance cost of about 22%. Thus, it is quite practical for the initial development and evaluation of replication algorithms. Several algorithms have already been implemented within the framework.

No abstract