oracle-databasejdbcwebsphereora-01017

WebSphere to Oracle - doesn't accept correct password


In WebSphere 6.1 I have created a datasource to an Oracle 11g instance using the thin JDBC client.

In Oracle I have two users, one existing and another newly created.

My websphere datasource is OK if I use the component-managed authentication alias of the existing user, but fails with "invalid user/password" message if I use the alias of the new user. The error message is:

The test connection operation failed for data source MyDB (Non-XA) on 
server nodeagent at node MY_node with the following exception: 
java.sql.SQLException: ORA-01017: invalid username/password; 
logon denied DSRA0010E: SQL State = 72000, Error Code = 1,017. 
View JVM logs for further details.

There is nothing in the JVM logs. I have grepped all websphere logs and they do not mention my connection at all.

I can confirm that the username and password are correct by logging in via SQLPlus or (to prove the JDBC connection is OK) via SQuirreL.

I have checked in Oracle that the new user has all the system privs that the existing user has.

Any thoughts on what is going on or how I can debug this further?


Solution

  • Just FYI. I am guessing you are running WebSphere in Network Deployment mode. This behavior you're experiencing is actually by design.

    The reason for it is that the "Test Connection" button you see on the admin console, invokes the JDBC connection test from within the process of the Node Agent. There is no way for the J2C Alias information to propagate to the Node Agent without restarting it; some configuration objects take effect in WebSphere as soon as you save the configuration to the master repository, and some only take effect on a restart. J2C aliases take effect on restarts.

    In a Network Deployment topology, you may have any number of server instances controlled by the same Node Agent. You may restart your server instances as you'd like, but unless you restart the Node Agent itself, the "test connection" button will never work.

    It's a known WebSphere limitation... Which also exists on version 7.0, so don't be surprised when you test it during your next migration. :-)