WebSphere Application Server V6.1.x requires Cloudscape to run at a minimal version of v10.1.x. (Note that Cloudscape v10.1.x is comprised of the code base from Apache Derby V10.1.) During the Application Server v6.1.x upgrade, the migration tool automatically upgrades the database instances that are accessed through the embedded framework by some internal components, such as the UDDI registry. The tool also attempts to upgrade Cloudscape instances that your applications access through the embedded framework. You must verify the migration results for these backend databases.
Do not use Cloudscape v10.1.x as a production database. Use it for development and test purposes only. Learn more: The new version of Cloudscape combines the Derby runtime with additional benefits, such as IBM Quality Assurance (QA) and national language support (NLS). For information about the Cloudscape v10.1.x open source code base, see the Cloudscape product Web pages link in the following IBM Suggests section.
The migration tool attempts to upgrade Cloudscape database instances that are accessed through the embedded framework only. You must manually upgrade Cloudscape instances that transact with application servers on the Network Server framework. (See the Upgrading Cloudscape manually article.) This requirement eliminates the risk of corrupting third party applications that use the Network Server framework to access the same database instances as WebSphere Application Server.
Other applications can access Cloudscape on Network Server because the framework provides the database with a foundation of connectivity software; the embedded framework does not. Cloudscape Network Server can transact with multiple Java Virtual Machines (JVM)s (or application servers) concurrently, whereas Cloudscape on the embedded framework works with only a single JVM. Clustered or coexistence implementations of Application Server require Network Server. For more information, consult the IBM Cloudscape Information Center. Find the link in the following IBM Suggests section.
To distinguish between a partially and a completely successful migration, verify the auto-migration results by checking both the general post-upgrade log and the individual database logs. Performing these tasks gives you vital diagnostic data to troubleshoot the partially migrated databases as well as those that fail auto-migration completely. Ultimately, you migrate these databases through a manual process.
MIGR0344I: Processing configuration file /opt/WebSphere51/AppServer/cloudscape /db2j.properties. MIGR0344I: Processing configuration file /opt/WebSphere51/AppServer/config/cells /migr06/applications/MyBankApp.ear/deployments/MyBankApp/deployment.xml. DSRA7600E: Cloudscape migration of database instance /opt/WebSphere61/Express /profiles/default/databases/_opt_WebSphere51_AppServer_bin_DefaultDB failed, reason: java.sql.SQLException: Failure creating target db MIGR0430W: Cloudscape Database /fvt/temp/51BaseXExpress/PostUpgrade50BaseFVTTest9 /testRun/pre/websphere_backup/bin/DefaultDB failed to migrate <new database name>
Call IBM WebSphere Application Server Support if you see a migration failure message for a Cloudscape instance that is accessed by a WebSphere internal component (that is, a component that helps comprise WebSphere Application Server rather than one of your applications).
The path name of each database log is WAS_HOME/profiles/profileName/logs/myFulldbPathName_migrationLogtimestamp.log.
MIGR0429I: Cloudscape Database F:\temp\51BaseXExpress\PostUpgrade50BaseFVTTest2\testRun \pre\websphere_backup\bin\DefaultDB was successfully migrated. See log C:\WebSphere61 \Express\profiles\default\logs\DefaultDB_migrationLogSun-Dec-18-13.31.40-CST-2005.logOtherwise, the log displays error messages in the format of the following example:
connecting to source db <jdbc:db2j:/fvt/temp/51BaseXExpress/PostUpgrade50BaseFVTTest9 /testRun/pre/websphere_backup/bin/DefaultDB> connecting to source db <jdbc:db2j:/fvt/temp/51BaseXExpress/PostUpgrade50BaseFVTTest9 /testRun/pre/websphere_backup/bin/DefaultDB> took 0.26 seconds creating target db <jdbc:derby:/opt/WebSphere61/Express/profiles/default/databases /_opt_WebSphere51_AppServer_bin_DefaultDB> ERROR: An error occurred during migration. See debug.log for more details. shutting down databases shutting down databases took 0.055 seconds
java.sql.SQLException: Database_opt_WebSphere51_AppServer_bin_DefaultDB already exists. Aborting migration at com.ibm.db2j.tools.migration.MigrateFrom51Impl.go(Unknown Source) at com.ibm.db2j.tools.migration.MigrateFrom51Impl.doMigrate(Unknown Source) at com.ibm.db2j.tools.MigrateFrom51.doMigrate(Unknown Source) at com.ibm.ws.adapter.migration.CloudscapeMigrationUtility.migr
Class type | Old value | New value |
---|---|---|
JDBC provider class path | ${CLOUDSCAPE_JDBC_DRIVER_PATH}/db2j.jar | ${DERBY_JDBC_DRIVER_PATH}/derby.jar
|
Data source implementation class: Connection pool | com.ibm.db2j.jdbc.DB2jConnectionPool DataSource | org.apache.derby.jdbc.EmbeddedConnection PoolDataSource |
Data source implementation class: XA | com.ibm.db2j.jdbc.DB2jXADataSource | org.apache.derby.jdbc.EmbeddedXADataSource |
Data source helper class | com.ibm.websphere.rsadapter.Cloudscape DataStoreHelper | com.ibm.websphere.rsadapter.Derby DataStoreHelper |
Additionally, the db2j.properties file changes:
Note the exact path names: For both partial and failed migrations, the log messages contain the exact old and new database path names that use to run the manual migration. Note these new path names precisely.
For
successfully migrated Cloudscape instances, be aware that new cell-scoped
data sources can only be used by nodes that run version 6.0.2 or later of
the application server. Earlier versions of the product do not support the
new Cloudscape; when applications on pre-version 6.0.2 nodes try to access
a Cloudscape 10.1.x data source, the application server will issue exceptions
at run time.
  Â