Show TOC Start of Content Area

Background documentation Application Server's Robustness and High Availability  Locate the document in its SAP Library structure

Robustness of Java

Most people who have used Java as a language and programming environment to run business applications know that the robustness and stability of current application servers is still problematic for mission critical solutions. Primarily this is an architectural problem of the way how Java runtime behaviors were initially designed several years ago. In those days the main focus of Java was to provide a programming environment more for embedded devices as for full blown business applications. In embedded scenarios only one parallel user is normally working with one program – this is completely different to business scenarios where many concurrent users are working with a set of applications.

Therefore nowadays we see application servers running several business applications for many users in parallel but still relying on architectural decisions made under different conditions. This can result in stability issues of the whole application server if one application or user session is going down or is running out of control. This can lead to a VM crash and as a consequence in data loss for all users since their sessions will be gone too.

Isolation – the Road to Robustness

To overcome this problem our goal is to provide a stronger isolation between those user sessions. The most important measure is to save all inactive user sessions - those which are waiting for the next request of the associated user – in a safe spot, which survives the VM crash. In general this is a common concept – usually many application servers allow storing those sessions via Java serialization inside of the database or file system. The problem with this approach is, that both the Java serialization as well as the interaction with the persistency (file system or database) is time consuming. Especially in the case of larger session (which is usual in the case of large business applications) this will result in a significant performance degradation of the system. As a result only a few sessions can be made failover safe – the rest will still die together with a crashing VM resulting in a bad user experience.

Our technique to solve these issues is based on two main approaches: make the process of bringing the session into the persistency faster and choose the fastest persistency we can find. Both concepts are based on the SAP Java VM. Additionally the application server provides means to store incoming requests also in a failover safe queue until they can be processed. Therefore, also waiting requests will survive VM crashes thereby enhancing the overall user experience.

SAP Java Virtual Machine

SAP offers the SAP Java Virtual Machine (SAP JVM) to address the pain points mentioned above. It is build on top of Sun Microsystem’s HotSpot Java Virtual Machine, version 5. The SAP JVM introduces the shared memory concepts for sessions. Utilization of shared memory results in the following benefits:

      Minimized memory footprint of an additional server node

      Fast and reliable shared memory-based persistency for Java objects structures (for example, sessions)

      On-the-fly debugging and hot code replacement

      Shared memory-based monitoring of system resources (server processes, threads, sessions and so on)

As a result the SAP JVM provides both enhanced supportability capabilities (monitoring, debugging) as well as the basis to enable a fast and reliable session failover concept.

More information: SAP JVM.

Advanced Session Failover Safety

The basic approach is based on the idea to save all important user sessions in the shared memory. Since the shared memory is independent from a specific VM process it will survive a VM crash if there is at least one server process running in the Java instance. The main advantage is obviously the fast access and performance of the shared memory compared to all the other persistency options which are on the table. Based on that concept in principal it is possible to make all sessions failover safe. For the application developer it’s based on common Java standards and not on proprietary extensions – the advantages are hidden under the hood of the application server. Nevertheless it’s still possible to use the standard failover mechanisms via Java serialization e.g. into the database.

This graphic is explained in the accompanying text

If now a VM crash is happening the application server takes care of migrating the sessions inside of the shared memory to another still running node on the same machine. This is completely transparent for users and does not affect the user experience. Since the shared memory based approach allows ensuring failover safety on one physical machine there might still be the need to save the most important sessions in the central database, which allows cluster-wide failover safety. Therefore, in a standard usage scenario only few sessions will be failed over to the database – most of the sessions will be handled by the shared memory based mechanism. This allows having most sessions running in a failover safe mode with minimal performance degradation of the system.

Advanced Debugging

To enhance supportability capabilities the SAP JVM allows on-the-fly debugging. This means it is possible to switch the Virtual Machine into debug mode without any need to restart it. Considering the seamless integration with the SAP Management Console (SAP MMC), this is possible with a single click. In addition, it is possible to debug applications in productive environment without interrupting productive requests on the same VM and use “hot code” replacement to fix application errors on-the-fly.

Zero Administration Capabilities

Those capabilities allow reducing the administrative efforts (and therefore costs) to set up and run a system landscape. This also means that the overall TCO of the system is decreasing. Scenarios supported by this concept are the initial system setup, as well as scaling the system by adding new servers. The configuration is based on templates, which are containing most parts of the configuration based on specific business scenarios. This flexible approach allows slightly modifying and adapting preconfigured settings easily.

More Information

Architecture of AS Java

 

End of Content Area