(As far as I can tell, anyway... most of the images on that page don't display for me.)
When I deploy my EAR and attempt to run the code that hits the Teradata database, I get an exception (shown below). I've tested the code via Junit tests (using a non-pooled connection injected by Spring), and the code does seem to be working properly. So, I'm fairly confident that the problem is related to my WebSphere setup or to EAR that is being deployed.
From what I've read so far, exceptions from TdgssConfigApi.GetMechanisms() usually imply a missing tgdssconfig.jar. However, I do have that jar listed in my classpath, and the jar that's referenced is the same one that's being used by my unit tests.
I'm a little lost. Can anyone suggest what I should be looking for next?
--- Cause: java.sql.SQLException at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryWithCallback(MappedStatement.java:201) at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryWithRowHandler(MappedStatement.java:149) at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryWithRowHandler(SqlMapExecutorDelegate.java:601) at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryWithRowHandler(SqlMapSessionImpl.java:156) at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryWithRowHandler(SqlMapClientImpl.java:132) at com.nwa.cpax.dao.impl.AbstractDao.selectWithRowHandler(AbstractDao.java:262) ... 8 more Caused by: java.sql.SQLException at com.ibm.ws.rsadapter.AdapterUtil.toSQLException(AdapterUtil.java:1507) at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:659) at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:613) at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) at org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy$TransactionAwareInvocationHandler.invoke(TransactionAwareDataSourceProxy.java:210) at $Proxy27.prepareStatement(Unknown Source) at com.ibatis.sqlmap.engine.execution.SqlExecutor.prepareStatement(SqlExecutor.java:497) at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor.java:175) at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.sqlExecuteQuery(MappedStatement.java:221) at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryWithCallback(MappedStatement.java:189) ... 13 more Caused by: javax.resource.spi.ResourceAllocationException at com.ibm.ejs.j2c.FreePool.createManagedConnectionWithMCWrapper(FreePool.java:2207) at com.ibm.ejs.j2c.FreePool.createOrWaitForConnection(FreePool.java:1609) at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:2436) at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:955) at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:609) at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:646) ... 21 more Caused by: java.lang.NullPointerException at com.teradata.tdgss.jtdgss.TdgssConfigApi.GetMechanisms(DashoA1*..) at com.teradata.tdgss.jtdgss.TdgssManager.(DashoA1*..) at com.teradata.tdgss.jtdgss.TdgssManager.getInstance(DashoA1*..) at com.teradata.jdbc.jdbc.GenericTeraEncrypt.getGSSM(GenericTeraEncrypt.java:622) at com.teradata.jdbc.jdbc.GenericTeraEncrypt.getConfig(GenericTeraEncrypt.java:640) at com.teradata.jdbc.jdbc.GenericTeraEncrypt.getUserNameForOid(GenericTeraEncrypt.java:733) at com.teradata.jdbc.AuthMechanism.(AuthMechanism.java:50) at com.teradata.jdbc.jdbc.GenericInitDBConfigState.action(GenericInitDBConfigState.java:104) at com.teradata.jdbc.jdbc.GenericLogonController.run(GenericLogonController.java:49) at com.teradata.jdbc.jdbc_4.TDSession.(TDSession.java:201) at com.teradata.jdbc.jdbc_3.ifjdbc_4.TeraLocalConnection.(TeraLocalConnection.java:99) at com.teradata.jdbc.jdbc.ConnectionFactory.createConnection(ConnectionFactory.java:58) at com.teradata.jdbc.TeraDataSourceBase.createNewConnection(TeraDataSourceBase.java:757) at com.teradata.jdbc.TeraPooledConnection.getConnection(TeraPooledConnection.java:120) at com.ibm.ws.rsadapter.spi.WSRdbDataSource.getConnection(WSRdbDataSource.java:2195) at com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl.createManagedConnection(WSManagedConnectionFactoryImpl.java:1432) at com.ibm.ejs.j2c.FreePool.createManagedConnectionWithMCWrapper(FreePool.java:1874) ... 26 more
Yes, there's a problem with the images for the WebSphere How-To document that is posted here on Developer Exchange.
You can also find the document (with images) in the Teradata JDBC Driver documentation section of the Download Center: http://www.teradata.com/DownloadCenter/Forum98-1.aspx
You are correct that the NullPointerException from TdgssConfigApi indicates that tdgssconfig.jar could not be accessed. There's usually a very simple explanation for why the jar file can't be accessed. For example, perhaps the jar file name is misspelled in the classpath used for WebSphere.
Well, I don't claim to fully understand this, but it looks like I can fix my problem by using *exactly* the same strings as the How To when I set up the JDBC provider. So, I had to use "Teradata Driver" for the name, and "Teradata JDBC" for the description.
I didn't think the name was supposed to be significant, but I've tried this on two different PCs, and each time it failed when I named the provider "Teradata" and started working when I named it "Teradata Driver". That's not a very satisfying explanation, but I'm not going to push my luck this close to the weekend.
Unfortunately, this is more complicated than I gave it credit for. As of this morning, the connection is failing again, exactly as before, on both of my test Windows machines (Win2k and WinXP). WebSphere was stopped over the weekend and was restarted this morning, but that's the only difference from last Friday night.
I also deployed to two different AIX servers on Friday night and let my code run over the weekend. According to the logs, everything worked over the weekend. However, I just rebooted one of those servers (no code or config changes, just a stop/start of WebSphere) and now the connection fails with the exception shown above. I tried a few desperate work-arounds: rebooting the server, redeploying the application, deleting and re-creating the JDBC configuration from scratch, etc., but nothing made a difference.
The second AIX server, which has not been rebooted, is still working fine. Also, unit tests continue to work outside of the container using the simple TeraDriver.
Any other suggestions? At this point, I'm willing to try just about anything.
Just to tie this off, I gave up on pooled connections. The application only needs to run one report once per day from this data warehouse, so I can live with a single connection. I'm using a pseudo-pool implemented by org.apache.commons.dbcp.BasicDataSource and injected directly out of my Spring application context. This seems to work more consistently.