Roy's musings

Recently one of the applications that I developed started throwing exceptions, that had the following message: SQL state [72000]; error code [1013]; ORA-03111: break received on communication channel When I googled around, I couldn't come across anything useful. Sadly enough most of the sites just showed the documentation for that error, without any explanation from anyone experiencing that issues. So here you go, with the best possible explanation that I could come up with. My application sets two things on the connection that is throwing this exception: It sets the fetchSize to be 2500 rows It sets the query timeout to be 10 seconds The database server and the application are separated over a long latency network (actually there is a NetEm box that emulates the long latency between these two boxes) which has a latency characteristic of 50+/-5 milliseconds. This is the whole setup. It is important to understand how the timeout is handled by the Oracle client (in my case JDBC clien...

Keep the following things in your mind if you are planning to measure the time taken to execute a query when you make use of Apache DBCP + Spring JdbcTemplate. You will never be able to find out the time taken to execute a query in the database by measuring the the time it takes to complete any variant of JdbcTemplate.query...() or JdbcTemplate.execute...() . Making use of any of these functions involve the following steps: Time taken to borrow a connection from the pool Time taken to create a statement from the connection and bind the parameters if needed Time taken to send the query to the database Time taken to execute the query in the database ( this is the time you are specifically interested in ) Time taken to receive the result from the database (depending on the fetch size you have set, this will vary). For UPDATEs, only the update count is sent back from the database. Time taken in the row mapping (if you are making use of RowMapper) or time taken to consume all the rows from...

This is a quick follow up to my earlier post on JDBC batch update return codes. There are two constants that you can conveniently make use of to check the error codes available in java.sql.Statement: SUCCESS_NO_INFO - The UPDATE or INSERT corresponding to this input values has succeeded but the number of rows that it affected is unknown. EXECUTE_FAILED - The UPDATE or INSERT corresponding to this input values has failed.

Recently I had to make use of the JdbcTemplate.batchUpdate() facility in Spring. I was connecting to the Oracle database using Oracle JDBC driver. As per the documentation, the batchUpdate() function is supposted to return an integer array. Each element in the array contains the number of rows affected the respective INSERT/UPDATE/DELETE query in the batch. But during my testing I found that, I was always getting all the elements to be -2. Initially I was thinking it was a bug in the driver code. Then when I was referring to the JDBC Programmers Guide , I figured the following: For a prepared statement batch, it is not possible to know the number of rows affected in the database by each individual statement in the batch. Therefore, all array elements have a value of -2 . According to the JDBC 2.0 specification, a value of -2 indicates that the operation was successful but the number of rows affected is unknown. There are more examples and explonation of error codes in the same page . ...