I have an app that utilizes several datasources, all on Oracle. I just added another datasource today whose associated database is configured a little differently than the others, but that may be irrelevant. I changed the app to use the new datasource, and it appears to be working fine.
However, I'm now seeing lines like the following in my log:
<2-Aug-2012 2:02:14 o'clock PM PDT> <Error> <JDBC> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "newds" failed with exception: "oracle.jdbc.xa.OracleXAException".>
I tried turning on all the obvious Weblogic debugging flags with JDBC in the name, but I didn't see any additional information in the log around this error.
What can I do to get more information about this?
If an Oracle RAC instances goes down, WebLogic Server attempts to determine the status of the of the database using the SELECT 1 FROM DUAL query. This query typically takes less than a few seconds to complete. However, if the database response is slow, WebLogic Server gives up and assumes the database is unavailable.
You can set the WebLogic Server parameter, -Dweblogic.resourcepool.max_test_wait_secs=30 to increase the time WebLogic Server waits for a response from the database. This parameter is located in the setDomainEnv.sh file. By setting this parameter, WebLogic Server waits 30 seconds for the database to respond to the SELECT 1 FROM DUAL query before giving up.
Thanks & Regards,
Your symptom implies that the XA connection that WebLogic is testing was left in
a broken/incomplete transactional state at the end of it's last use. This is likely
to be a WLS JTA bug which has a patch. Open an official support case.
Just in case someone else runs into this, I should at least document what's happened.
I've resolved this situation, but only because the DBA group decided to give me a "direct" connection, instead of the "proxy" credentials they had given me before. No more exceptions, no more query failures. I had filed a support case before this point, but before I got to the point of giving them all the diagnostics they asked for, I got the new connection info, which fixes the problem. I suppose I could have continued to repeat the problem if I had configured my application locally to use the old "proxy" credentials and then gotten them all the diagnostics they wanted to eventually get more information, but none of that work was worthwhile to me, so I closed the case.