Random NullPointer inside ojdbc14.jar

Question

Hi,
I have been experiencing this NullPointerException randomly when calling a callable statement. This pops up randomly throughout the day and annoyingly goes away when I try to debug.
We are running an 11g database with java 6. Any help would be greatly appreciated.
java.lang.NullPointerException
at oracle.jdbc.driver.OraclePreparedStatement.processCompletedBindRow(OraclePreparedStatement.java:2014)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3495)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3584)
at oracle.jdbc.driver.OracleCallableStatement.executeUpdate(OracleCallableStatement.java:5289)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:101)

Answer 1

sjasja wrote:
I seriously doubt that is supposed to mean concurrent access from different threads.
Consider one thread doing stmt.setString(1, "hello") and another doing stmt.setString(1, "world"). When whichever thread (perhaps a third one) does stmt.executeUpdate() what is the value of the first parameter?The same connection, not the same statement. Two different things. Each statement should, of course, be created, used, and thrown away. They should always be as local as possible. This should never happen.
>
We have objects (Connection, Statement) which have state. They have setters. When you set their state from two threads you get a mess unless the implementation works hard to have thread-independent value sets.
No one said that the programmer should not take a least a little bit of care in what (s)he does concurrently, but that does not mean that you can't use the same Connection in multiple threads. I have done it on a number of occassions, without problem (which does not necessarily make it correct). There is a problem with commit and rollback, but as far as one thread wanting autoCommit and the other not, that is a design choice that should be settled before the programming even begins, and so is a moot point, and, hopefully, people realise that there is a possible commit/rollback problems and do what they can to mitigate it. As far as the connections "properties", that would probably fall into another design before programming category, so that the info is set once at connection time, and the threads don't change it.
The only way it could work if there was a clear mandate to the implementations for multi-thread access to be handled magically; somehow forking the object state for each thread. It would require quite explicit trickery in the implementation; copious use of ThreadLocal or something. I can't see such a mandate. I don't think it should be expected by default.Noone said it was explicitly "thread-safe" as far as connection wide attributes and functions are concerned. It should be fairly obvious that it wouldn't be, but nothing you can do with a Statement or ResultSet should have an effect on what another, unrelated, Statement/ResultSet is doing. SQL that modifies the DB not withstanding, of course.
>
Unless explicitly otherwise specified (which it isn't), Statement.setXxx() has the thread safety of ArrayList.set(), i.e. none.True, but it is not Statement we're talking about here. And, even if it were, you should only be using a Statement object as locally as possible, so Threads should not be an issue here, anyway.
Ditto for Connection's state setter methods.True, but I still don't see the real problem. Connection wide attributes should be set when the connection is created, and if the connection is to be shared, it should be done before the sharing. No problem. The only remaining problem is commit and rollback, and as I have already said, that becomes, then, a design issue.
Edit: Nevermind the statement about it being not statement we're talking about. Now that I look closer we are (somewhat), but more so about Connection. I agree that a single statement should not be shared, but I see Connection differently (with care, of course).