WLS9.2 caching results of CallableStatement?

Question

Hello All,
I've been flummoxed by a problem in which the results of a CallableStatement seem to be cached by our WebLogic 9.2 server. We have a connection pooled DataSource talking to Oracle8i (8.1.7.4.0), configured with 10 statements in a cache and the LRU algorithm, also 1 connection initially and a maximum of 15. We're using Oracle's ojdbc14.jar implementation and orai18n.jar.
We're mostly executing CallableStatments for packaged procedures/functions that in turn call other procedures or run selects. What I'm geting at is, we're retrieving data rather than updating through our CallableStatement. The retreieved data we extract from the returned oracle ARRAY type using a homegrown map to the "shape" of each Struct underlying the ARRAY collection. In this problem, two CallableStatements are run and return data to our Java app, and at the start all is well. Then the underlying data is changed - via procedures in an oracle forms app on the database, not our Java app. Our Java app should display the changed data. The first CallableStatement runs again and an Eclipse remote debug shows the updated data, however the second CallableStatement continues to return the older data. We have oracle test harnesses that call the same procedures as our CallableStatements; both return the new data. If we leave it for sometime less than 45 minutes, the new data is then returned by both statements. Similarly, if we set the statement cache size to 0, the newe data is returned both times. We're closing the DB resources, (and in the right order: ResultSet, Statement and Connection)
Has anyone come across this issue before? (From my searches it appears not). Secondly, is there a way of debugging into the WLS DataSource mechanism? I can go down as far as getting the ARRAY and no further, but if there's a switch/command line arg that I could use in the startWeblogic script that'd be great. I remember reading about a WebLogic attributeSpy, (or maybe spyAttribute?) and if I had to try the WLS driver for that I'd give it a go, but if Oracle have something similar that'd be fantastic.
FWIW, changing the data via the oracle forms app changes the sysdate on the oracle database too.
Variables from the debug that might be relevant:
DataSource retrieved from jndi context of type WLEventContextImpl
driversettings
weblogic.jdbc.rmi.internal.RmiDriverSettings{verbose=false chunkSize=256 rowCacheSize=0}
driverProps entrySet [EmulateTwoPhaseCommit=false, connectionPoolID=xxxxx, jdbcTxDataSource=true, LoggingLastResource=false, dataSourceName=xxxxx]
Connection is PoolConnection_oracle_jdbc_driver_T4CConnection
weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@5f1
statement     is CallableStatement_oracle_jdbc_driver_T4CCallableStatement (id=nnnnn)     
weblogic.jdbc.wrapper.CallableStatement_oracle_jdbc_driver_T4CCallableStatement@5f2
There is a StatementHolder too:
weblogic.jdbc.wrapper.CallableStatement_oracle_jdbc_driver_T4CCallableStatement@5f2=weblogic.jdbc.common.internal.StatementHolder@21cae26
In the "stmts" table in "conn" in "stmt", there are the following two variables:
jstmt     T4CCallableStatement (id=nnnnn) oracle.jdbc.driver.T4CCallableStatement@21cad44
key     StatementCacheKey (id=nnnn)     { call my_pack_name.my_proc_name(?,?)}:true:-1:-1
Thanks for any help that anyone might be able to shed on this!
Best Regards,
ConorD

Answer 1

Hi Joe,
Thanks for your reply; I'm delighted to see that you're still here helping WLS users under the Oracle banner :-)
To answer your question, yes, we do get good behaviour when we set the statement cache size to 0. I ran a test on that where I set the Statement cache size to 0 and the initial number of connections to 0, then:
*1)* Logged in through our Java/WLS app to a few test scenarios and saw the data
*2)* Ran the oracle app on that DB outside of WLS which moved forward the state of the app, including sysdate
*3)* Logged in again through our Java/WLS app to the test scenarios and saw the new data being returned from both CallableStatements
I don't think that the initial number of connections had any effect on this, since WLS was running all the time and there was no retargetting of the DataSource, so IMHO it must have been the statement cache size.
Where we hadn't got the Statement cache size 0, for step *3)* above one of the two CallableStatements continued to return the old data, (as if it had been told by the DB that the result hadn't changed, and it might as well return a cached result - if WLS does cache ResultSets?)
Lastly, there is one case where we do see good behaviour even with a Statement cache size of 10:
Between steps *2)* and *3)* above, if I untarget & activate, then retarget & activate the DataSource (to the same server/db that had just been untargetted) we see new data back from both statements on running step *3)*, even with the Statement cache size set to 10. My guess is that the untarget frees up any object in the Statement cache for collection and removes the remote DB session stubs that may be caching on the DB side.
Thanks again and Best Regards,
ConorD