Migrating an application to Websphere clusters

Question

What we need to take care of before moving an application from one Websphere application server to a Websphere cluster

Answer 1

This is my experience list. It is not complete, but should cover the most common problem areas:

• Plan your distributed session management configuration (i.e. you will use memory or memory based replication). Please note that if you are still on a 32-bit platform, due to lack of resources from clustering, there may be instability problems if your application is already using a lot of memory.
• Make sure that everything that you put in user sessions can be serialized using the default serializer (implements Serializable). Otherwise, you might run into problems with distributed sessions.
• The same goes for everything you invest in DynaCache. Make sure everything is serialized correctly.
• Specify and verify that all resource definitions (JDBC providers, etc.) are made in the correct scope. I usually recommend using the actual cluster area for everything that your applications install for use by the cluster. This ensures that the test functions work properly from the right points and that you do not make conflicting definitions.
• Make sure your application uses relative paths for resources in the web interfaces. Once you start load balancing and stuff, you can run into serious problems if you have a lot of things.
• If you have any timers, make sure they work well with clusters. With Quartz, this means that you must use JDBC repository for timer tasks. Using EJB Timers, make sure that you register timers only once (the WAS timer database may be damaged if you have several nodes trying to register the same time) and make sure that you set them in the cluster area.
• Make sure you use the WAS-provided SSO mechanisms. If you have a custom implementation, make sure that it handles the user between servers in the cluster.

Answer 2

Keep it simple, depending on your requirements, try setting up a load balancer to use sticky sessions and not save state in an HTTP session. Thus, you do not need to use a resource hungry in replicating a memory session.

Single sign-on is not a problem for a single cluster, as your HTTP clients will not be moving with the same http://server.acme.com/ . host domain name.

Most of your testing should focus on database conflict. If you have a very transactional application (i.e. many records in the same table), make sure that you look at the database isolation levels so that the locks do not work properly. The same goes for transaction demarcation. Keep transactions as concise as possible. If you do not have database skills, make sure you get database analytics to help you control the database during testing.

Answer 3

It is also recommended that you obtain a PMR to support IBM before any major changes, such as this or updating to new versions, etc. Raise it as a “Question about the use of software” and they can provide you with feedback from their knowledge database based on the use of other clients. The same applies to any type of product with which you have a support agreement — ask for support before problems arise.