Tips for changing your Portal datasources

Graham — Tue, 04 Aug 2009 05:33:09 +0000

For some reason, we’ve got a test system that is hooked up to a db2 database that is using DHCP. This would be ok if Portal was configured to talk to the hostname of the database server, but it’s using the IP. So the inevitable happened and the IP of the database changed and the Portal server went down.

So the obvious fix is to change the datasource so it’s using the hostname of the database server, rather than the ip (or set a static IP for the database server, but that wouldn’t really require a whole blog post now would it!).

To do this, fire up the WAS admin console and navigate to datasources.

Your list of datasources might be different to mine, depending on your database, but the principles are the same.

Go into each datasource and at the bottom you will see a properties dialog. Change the old IP to a hostname.

change the IP

All of them need to be changed, so go back into each one and change it. Now run the test, by selecting each one and clicking the test connection button.

You should get a message like this:

successful test connection message

Now start Portal. Hmm, I get this when I try to go to the site….

” Error 404: Initialization of one or more services failed. ”

Check the SystemOut.log :

Caused by: com.ibm.websphere.ce.cm.StaleConnectionException: [ibm][db2][jcc][t4][2043][11550] Exception java.net.SocketException: Error opening socket to server /9.185.226.121 on port 50,000 with message: Operation timed out: connect:could be due to invalid address.DSRA0010E: SQL State = null, Error Code = -4,499

at sun.reflect.GeneratedConstructorAccessor64.newInstance(Unknown Source)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:522)

at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapExceptionHelper(GenericDataStoreHelper.java:523)

at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapException(GenericDataStoreHelper.java:578)

at com.ibm.ws.rsadapter.AdapterUtil.mapException(AdapterUtil.java:2159)

... 11 more

Hang on, the datasource test worked? Why won’t the server start? It looks like it’s using the old database server IP still!

The answer lies in the transaction logs that WAS uses. These binary log files contain XA transactions that might not have been executed yet. You should take care when messing about with these files – they are there for a reason. But on the other hand, the server won’t start now, so we can hardly make things worse, can we ) . Stop the server1 and WebSphere_Portal application servers and go to your wp_profile directory. Delete the contents of the tranlog and recoverylogs directories and try to start the server again.

This message should appear in SystemOut :

[4/08/09 15:23:16:825 EST] 00000012 LogHandle I CWRLS0007I: No existing recovery log files found in C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\tranlog. Cold starting the recovery log.

[4/08/09 15:23:16:825 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\tranlog\log1.

[4/08/09 15:23:16:841 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\tranlog\log2.

[4/08/09 15:23:16:856 EST] 00000012 LogHandle I CWRLS0007I: No existing recovery log files found in C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\partnerlog. Cold starting the recovery log.

[4/08/09 15:23:16:856 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\partnerlog\log1.

[4/08/09 15:23:16:856 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\partnerlog\log2.

[4/08/09 15:23:16:903 EST] 00000012 RecoveryManag A WTRN0028I: Transaction service recovering 0 transactions.

Success, now the server will start up!

Checking the version of the Oracle JDBC driver jar

Graham — Fri, 20 Mar 2009 08:38:47 +0000

I’m working on a problem now where we need to use the Oracle 10g driver against a 9i database. There’s a note in the infocenter about it .But how to do you check which version of the driver you are using ? The filename of the driver is the same between each version of Oracle (ojdbc14.jar), so that’s not going to do it.

To check it out, unzip the driver and read the META-INF/MANIFEST.MF file. Here’s mine:

Manifest-Version: 1.0
Specification-Title:    Oracle JDBC driver classes for use with JDK14
Sealed: true
Created-By: 1.4.2_08 (Sun Microsystems Inc.)
Implementation-Title:   ojdbc14.jar
Specification-Vendor:   Oracle Corporation
Specification-Version: Oracle JDBC Driver version - "10.2.0.3.0"
Implementation-Version: Oracle JDBC Driver version - "10.2.0.3.0"
Implementation-Vendor: Oracle Corporation
Implementation-Time:    Fri Sep 29 09:43:24 2006

Also Portal (and regular ol’ Appserver) will tell you as they initialize in the SystemOut.log, just try this trusty command :

cat SystemOut.log | grep -A 2 “Oracle JDBC”

and you get back something like :

[3/20/09 2:44:21:570 EDT] 0000001f InternalOracl I   DSRA8205I: JDBC driver name : Oracle JDBC driver
[3/20/09 2:44:21:572 EDT] 0000001f InternalOracl I   DSRA8206I: JDBC driver version : 9.2.0.8.0
[3/20/09 2:44:21:575 EDT] 0000001f InternalOracl I   DSRA8212I: DataStoreHelper name is: com.ibm.websphere.rsadapter.OracleDataStoreHelper@39136937.

What! 9.2.0.8! Looks like I’ve got the wrong one on there.

Tork Wrench » jdbc

Tips for changing your Portal datasources

Checking the version of the Oracle JDBC driver jar