Updating the instance interactively

After you updated the database by running the updatedb utility, use the interactive method to update any existing instances to the same fix pack level.

Before you begin

Ensure that you completed the following tasks:

Information about clustered environments

If you are installing a maintenance package to your WebSphere Commerce application, which is deployed to a clustered environment, the maintenance package is installed by using the rollout update process. Rollout update is a means to achieve high availability for clustered environments. Not all nodes in the cluster need to be shut down during the process. The deployment manager chooses one node and stops the server only on that specific node. After the updates for the nodes are synchronized, the server is started again. The process is repeated for each node in the cluster. Whether rollout update is safe to use with a deployment highly depends on the deployment payload and its payload dependencies. During the rollout update process, the cluster is in a state where some nodes are updated, but others are not. Deployment payloads that result in a code mismatch between the client/browser and the WebSphere Commerce server are susceptible to failure or unexpected behavior. Also, consider any database changes that client/browser code depends on. If the client/browser and the server are expecting a change to be present in the database, such as a new command in the CMDREG table, then the database should be updated before any code uses it. Performing rollout update on a test cluster while you access the cluster might help reveal any problems.

Rollout update is automatically enabled for clustered environments. Review the following information:

Ensure that you have the latest version of Update Installer.
Ensure that the WebSphere Commerce application is federated and clustered with two or mode nodes.
Ensure that you test the maintenance package on a non-production environment first.
To avoid save conflicts, ensure that the rollout update is not run at the same time as any other actions that also require an EAR update. For more information, see Troubleshooting: Save conflict error.
The WebSphere Commerce application is active when the maintenance packages are applied. The rollout update runs for a longer time when compared to the regular process of applying fixes. The nodes in the cluster are being updated sequentially rather than in parallel. This means that some nodes in your cluster contain updated code while other nodes do not. Ensure that this condition is feasible for your environment, especially if you are using customized code.

If you do not want to use the rollout update process for your clustered environment, then complete the following steps:

Open the WC_installdir/instances/instance_name/properties/earUpdateControl.properties file.
Edit the earUpdateControl.properties file by setting all values to false instead of true.

Important:

If you have a database performance concern, consider having your database administrator tune the database before the maintenance package update to the WebSphere Commerce instance. If the database is poorly tuned, the update command might run a long time. See your database manual for specifics of tuning the database.
Each new WebSphere Commerce instance that is created after you applied the maintenance package to your WebSphere Commerce installation directory, is created at that specific maintenance level.
If you have multiple WebSphere Commerce instances and you disable rollout update, then you must repeat the installation of the maintenance package for each instance.

About this task

For clustered environments, review the following information:

The WebSphere Commerce application is active when the maintenance packages are applied. The rollout update runs for a longer time when compared to the regular process of applying fixes. The nodes in the cluster are updated sequentially rather than in parallel. This means that some nodes in your cluster contain updated code while other nodes do not. Ensure that this condition is feasible for your environment, especially if you are using customized code.
During the rollout update process, if a lower failover time is required OR if the following message is posted in the browser window:
```
Servlet has become temporarily unavailable for service
```
See the plugin-cfg.xml file and make the following changes to decrease the failover time:
- ServerIOTimeout: Reduce to 30
- ConnectTimeout: Reduce to 15
Also, consider modifying the following properties:
- WebContainer custom property: com.ibm.ws.webcontainer.ServletDestroyWaitTime
- JVM Custom Property: com.ibm.ejs.sm.server.quiesceTimeout
- JVM Custom Property: com.ibm.ejs.sm.server.quiesceInactiveRequestTime
If you see application exceptions in the server logs during the rollout update process, the default 60-second wait time might not be enough. Use the com.ibm.websphere.management.application.updatesync.appExpansionTimeout custom JVM property to increase the wait time.

Procedure

Complete the following steps to install the maintenance package to the WebSphere Commerce instance.

Log on with a user ID that is a member of the Windows Administration group.
Log on.
- Log on as the root user
  - If you are already signed onto the system, issue the command su - root. Do not use the command su root. This command does not load the necessary root user's profile and environment.
- Or log on as a non-root user that owns WC_installdir.
Ensure that the Configuration Manager server is stopped.
Ensure that your database is started.
Ensure that WebSphere Commerce administrative server is started.
- If WebSphere Commerce is managed by WebSphere Application Server Deployment Manager (dmgr), start the deployment manager and all node agents. Optionally, your cluster can also be started.
- If WebSphere Commerce is not managed by WebSphere Application Server Deployment Manager (dmgr), start the WebSphere Application Server server1.
Note: During the application of maintenance to the WebSphere Commerce instance, the Update Installer stops the WebSphere Commerce application automatically.
Using the command line, navigate to the UPDI_installdir directory and enter the following command:
- ./update.sh [-W update.exportearTimeout=interval]
- update.bat [-W update.exportearTimeout=interval]
Where

update.exportearTimeout

Optional: The maximum amount of allowable time (in minutes) for the export EAR process, which is exporting the WebSphere Commerce Application, to complete. If the export EAR process takes more than interval minutes, then a timeout error occurs. By default, the interval is set to 240 (minutes) but can be changed to suit your system needs. For example, -W update.exportearTimeout=360 allows for 360 minutes.
Complete the following steps in the Update Installer wizard.
1. On the Welcome panel, review the information and click Next to continue.
2. Specify the WebSphere Commerce installation directory or click Next to accept the WebSphere Commerce product found on your computer.
3. When prompted, specify the instance name from the drop-down list that you want to apply the fix pack to. Click OK to continue.
4. Select Install maintenance package and click Next.
5. Select the UPDI_installdir/maintenance directory and click Next.
6. On the Available Maintenance Package to Install page, select the appropriate maintenance and click Next to begin the installation.
  You are prompted to start exporting the WebSphere Commerce Enterprise application that you selected.
7. Click OK to export the application.
  This action takes several minutes.
8. On the Summary page, review the information and click Next to begin the installation process.
Ensure that the installer displays the message: Success:The following maintenance package was installed. If you do not see this message, the installer indicates which log files to check. Click Finish. to exit the Update Installer wizard.

After the installation process completes, and the Update Installer returns a success message, the rollout update is complete.

If you see an error during the update, increase the com.ibm.websphere.management.application.updatesync.appExpansionTimeout timeout value. Increase in 5-minute increments, do not use a value greater than 60 minutes.

[8/25/09 16:16:31:709 GMT+08:00] 00000017 TreeBuilder W ODCF0002E: Exception: java.lang.reflect.InvocationTargetException
.
Caused by: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.NestedJarException: 
IWAE0008E An error occurred reading InitializationServlet.war from /usr/WebSphere/AppServer/profiles/AppSrv01/config/cells/wci156pCell01/applications/WC_demo.ear/deployments/WC_demo
.
Caused by: java.io.FileNotFoundException: /usr/WebSphere/AppServer/profiles/AppSrv01/installedApps/WC_demo_cell/WC_demo.ear/InitializationServlet.war 
(A file or directory in the path name does not exist.)

For non-clustered environments, if you have a WebSphere Commerce instance, restart the WebSphere Commerce application.
Check the WC_profiledir/logs/server1/SystemOut.log file to ensure that the database version is at the same level as the EAR version.
For example, search for a message similar to the following message.
```
 0000000a SystemOut O WC.SERVER: Enterprise 8.0.0.X / Database: ENT 8.0.0.X
```
where X is the level of fix pack installed.
This message indicates that the EAR version and database version are the same version. The levels are retrieved from:

EAR

WC_profiledir/installedApps/cell_name/WC_instance_name.ear/properties/version/COMMERCE.product

Database

SITE

If the versions are not the same, contact IBM Support.
If you have both a staging and a production environment, you must perform the steps that are outlined in Step 5 of Installing maintenance package for WebSphere Commerce to ensure that the following actions are completed:
1. All the STAGLOG records that are inserted during maintenance package installation and instance update are deleted from the staging database.
2. If Access Control Policy is in a staging environment, run the stagingcopy utility.
If you encounter problems with stagingcopy, complete the following steps:
1. Update the STMTHEAP database configuration parameter for both staging and production server databases, db, to a higher value. For example:
  db2 update database configuration for db using stmtheap 240000
2. Similarly, update the APPLHEAPSZ database configuration parameter for both staging and production server databases, db, to a higher value. For example:
  db2 update database configuration for db using applheapsz 3000
3. Disconnect all users from both staging and production server databases.
4. Run the stagingcopy utility.
Update an alias name in three store JSP files.

Note: This steps is needed only if you installed Mod Pack 3, specifically 8.0.3.0.
If you are upgrading from 8.0.0.x or 8.0.1.x to 8.0.3.0 or later, then update your wc-server.xml file that is in your source code repository.

IBM updated the WC_eardir/xml/config/wc-server.xml file in 8.0.3.0.
Review Installing maintenance: Final steps to complete the installation. You might need to enable some fixes that are included in the maintenance package.