Java Web Application Upgrade Story From 1.2 to 1.5: Lessons Learned

We were busy during past months while upgrading our ERP application. The upgrade wasn’t a piece of cake for us. There are always 2 rules about upgrade; it has a cost and it is painful. If it contains many elements, then your compatibility combat begins. I want to share our journey and some lessons learned. We transformed 70 web applications and about 1000 db tables to new version. We couldn’t upgrade to the latest versions because of license and fear of probable bugs on latest versions.

Let’s look at the versions and elements of upgrade:

Before:
Java 1.2, WebSphere 3.5, DB2 7.1, VisualAge For Java 3.5, Team Repository

After:
Java 1.5 (5), WebSphere 6.1, DB2 9.1, Rational Application Developer For WebSphere 7.5, ClearCase 7.1


1. The most changing part was application configuration: In previous WebSphere version, we were using the file system for application elements and that path was defined as classpath in application server, that was ver easy with some disadvantages. In Java EE 5, EAR and WAR package structure are used. We had to map our applications to this new package system. Session, classpath and classloader behaviours are very closely related with this mapping.

There were 2 options for application packaging:
a-Packaging each web application as WAR within one EAR(One EAR): In WebSphere, we can’t restart WARs individually and install options are generally bound to EAR structure. Because of that, we didn’t select this option.

b-Packaging each web application as one WAR and one EAR(Many EARs): We used this option. In this option, every application can be started, stopped, upgraded without stopping application server. However, there is a shared session problem. In Java EE 5 specs, every WAR has its own independent session. WebSphere supports shared session among WARs within only one EAR.

Shared Session Problem Solution
We needed shared session through all web applications and EARs. What we did was, to develop “Shared Session Support Among EARs” ourselves. It wasn’t easy to achieve this, we had to use session invalidation events and then temporarily store the objects of invalidating session. When user enters that application, we filled the new session with the previuosly created session objects. Another interesting point is that WebSphere uses same Session ID for new web applicaions. For a certion user, session objects are differenet but session ID is same.

Shared Library Problem Solution
Another problem was configuring application classpaths. We needed 2 basic classpath (now called as “shared lib” in WebSphere) requirements for library visibility:

a- Inter-Application-Level Classpath: For instance, one application needs to see a certaion application classes. We should provide that visibility without adding to global container-level classpath. Fortunately, a WebSphere extension eanbled us to make such a configuration. What we did was to add WEB-INF/classes path to the shared lib section of other application. One note about that is you should choose “ClassLoader Multiple Policy”, otherwise your application restart doesn’t take effect since classloaders are not renewed.

b-Container-Level Classpath: This is required if you need global visibility of some libraries. This is achieved in WebSphere with ClassLoader creation in Admin Console. You firstly define your library as a shared lib. Then you create a new classloader containing that shared lib entries.


2. DB2 is perfectly stable: "DB2 is DB2 is DB2." This mantra holds true. The easiest element of upgrade was DB2. What we need is to restore a 7.1 backup image to 8.1 then again to restore its backup to 9.1 version. You can’t restore a backup of 7.1 version to directly to 9.1 version. One extra work was to migrating an AIX database to the Windows system. In DB2, you can’t restore a backup image from other OSs. There is a utility to export and import form one system to another: db2move

3. The hardest part was to configure ClearCase environment: From VisualAge, we exported source codes, then imported to the RAD, that was a straightforward task. The problematic part is to build a Team environment for source code. In VAJ, there were a basic and simple Team system. We had to become familiar with versioning concepts like “Check-in”, “Check-out”, “Hijack”, “Baseline”, “Branch”, “Activity” etc. Initial setup and configuration of ClearCase server was another rough job. We had to outsource that job to an external consultant. I strongly recommend that you should consult to someone else if you are not familiar with ClearCase and Eclipse connection. There are many confusing configuration options for ClearCase. We used web-client type with snapshot views. Its performance is not good but enough for now.

4. Upgrade periodically for performance: Yes, to update frequently is a cumbersome for agile teams but becoming too late may increase upgrade cost. New versions may bring not only new features but new performance improvements. In Java 1.2, the most bothering part was GC; it was stopping all applications. With Java 1.5, “Incremantal GC” performance is excellent. After the upgrade, users were very satisfied with performance. Report execution times decreased from 10 minutes to 10 seconds. Every team should plan and reserve a time for upgrade in their agenda.

5. SSD disks versus HDD disks: We bought some new servers during upgrade. In one server configuration, we used SSD disk for its famous performance advantages for db-driven applications. One mistake of us was to buy only 2 SSD disks, and using it with RAID1(mirroring) configuration. Its performance was equivalent with 4 SAS disks with RAID5 configuration. We needed to buy 2 new SSD disk(Using RAID5) for better performance. I found a benchmark which depict the case.

As I understand, even we use 4 SSD disks, its speed won’t be superior as we expected. I read many articles mentioning 4 or 10 times performance but we didn’t get it. (Our new servers were Dell PowerEdge.). Additionally, SSD disks are highly expensive compared with classical HDDs.

6. 32 bit versus 64 bit: We were unable to use 64 bit versions for some reasons. 64 bit version should be supported by OS, DB2 and WebSphere. For WebSphere, 64 bit means more heap space more than 1.5 GB. For DB2, 64 bit means larger memory for DB which is more than 3 GB. In 64 bit, DB2 buffer pools can leverage more memory and that may result good performance gain. WebSphere is also bundled as as 32-bit and 64-bit. WebSphere Express edition currently doesn't support 64-bit, expecting 64 support in coming releases.