IKEA is running an upgrade activity from v9.5 to v9.10 and we are running into a problem relating to how to handle JDBC pool connections, its target endpoint information and the associated username/password fields.
We are following the side-by-side upgrade guide procedure, by which we are performing the following steps:
-
Clone the old 9.5 databases (IS, TN, etc.) to new databases
-
Install v9.10 product components on new servers
-
Install database objects on the new databases
• Integration Servers are now up and running, pointing to the new (empty) databases -
Extract the v9.5 (zip files)
-
Run the migration scripts with a target v9.10
At this point in time, we have migrated the password store from the old environment to the new. We have not migrated the JDBC pool connection information since that is already ok. Starting up the Integration Server now will result in unable to connect to the database, because the password store is overwritten by the migration utility. The password handles defined in the JDBC pool configuration files are no longer present. IS tries to connect a few times and we are getting DB account locking, since the policy here is to allow only three attempts.
The question is how we should handle this situation.
- We must migrate the password store due to a large number of trading network partner profile information that we cannot re-apply easily.
- The password store does not merge the old v9.5 password store with the new (already existing) v10 store.
- We cannot / should not migrate the old JDBC pool configuration because we have new databases
- During failover, we must not run the migration utility on the “live” v9.5 database and point our new installation to the old. I.e. we are cloning the v9.5, and upgrading the clone DB which will be used for v10.
Some discussed workarounds:
- We have around 150 database connections defined for each release. This means that manually changing the JDBC connection parameters for each pool alias in the config folder would involve a huge extra effort
- We cannot stop the v9.5 source systems and update the connection parameters to the new (which would be used for extraction). There are too many servers involved and again a huge extra & manual effort.
- We also do not want to manually change the passwords in the new v9.10 databases for each and every user to reflect the old environment, and at the same time ensuring that the password handle is identical with the old v9.5. Again a huge manual effort.
- We do not want (manually) create new JDBC connection aliases on the old v9.5 environments to reflect the new v9.10 connections (too much of a manual effort).
Hoping there is a better alternative available than mentioned above.