Having trouble with lingering cursors.

Question

RHEL 5.2 Server
Java: Sun JDK 1.6.0_16 (64-bit)
Tomcat 6.0.20
Oracle 10g (10.2.0.3)
JDBC: ojdbc14.jar
I'm having a problem with running out of cursors. I've searched for them with these queries:
{noformat} SELECT a.sid,       b.status,       b.osuser,       b.machine,       to_char(b.logon_time, 'dd-mon-yyyy hh24:mi:ss') logon_time,       a.user_name,       a.sql_id,       a.sql_text   FROM v$session b,       v$open_cursor a WHERE a.sid = b.sid   AND a.user_name = 'APPUSERNAME' ORDER BY upper(a.sql_text),         b.status; SELECT count(a.sql_text) count,       a.sql_text   FROM v$session b,       v$open_cursor a WHERE a.sid = b.sid   AND a.user_name = 'APPUSERNAME' GROUP BY a.sql_text ORDER BY count desc,         upper(a.sql_text);{noformat}
The thing is, whenever I track down the SQL shown by these queries in my Java app (a webapp running under Tomcat), the Statement objects are always guaranteed to be closed by a finally block. Statement.close() closes the current ResultSet object and all of the Statement objects I've looked at have only one ResultSet. I am at a loss for how it's possible for these cursors to still be open. They seem to linger even though their ResultSet's must have been closed.
One thought I had was that it might be possible (though unlikely) that there are some transactions that are not properly doing a commit/rollback before returning the connection to the pool, and the next threads that get the connection may have their queries be considered part of that unfinished transaction until one of them does a commit/rollback, and if so, possibly still be considered as open cursors in the system until the transaction is committed/rolled back? Does that make sense? Is it a possibility?
Any other ideas as to why closed ResultSet's could be showing up in v$open_cursor?

Answer 1

OK. I managed to find an operation that when repeated can consistently drive
up the cursors and get the ORA-01000 again.
Checking for the open cursor count:
{noformat}
SELECT a.sid,
       a.value,
       b.name
  FROM v$sesstat a,
       v$statname b
WHERE a.statistic# = b.statistic#
   AND a.statistic# = 3
   AND a.value > 0
ORDER BY a.value DESC;
SID                    VALUE                  NAME                                                            
1074                   299                    opened cursors current                                          
1073                   42                     opened cursors current                                          
1096                   28                     opened cursors current                                          
1083                   7                      opened cursors current                                          
1084                   7                      opened cursors current                                          
1097                   4                      opened cursors current                                          
1080                   2                      opened cursors current                                          
1093                   1                      opened cursors current{noformat} This query:
{noformat}SELECT count(a.sql_text) count,
       a.sql_text
  FROM v$session b,
       v$open_cursor a
WHERE a.sid = b.sid
   AND a.sid = 1074
GROUP BY a.sql_text
ORDER BY count desc,
         upper(a.sql_text);{noformat}shows an update statement with 246 records in v$open_cursor. However, they all have different SQL ids. The SQL in question is dynamically generated in Java, but it is using a PreparedStatement. The parameters being plugged are different every time (it's changing data in a different row each time).
The statement.close() on this UPDATE is guaranteed to run from the finally clause; the same as all of the others I've tracked down.
I can't tell for sure that a commit is being done after the update, though it looks like it is. The code for transactions is not as nicely encapsulated and linear as it is for specific SQL calls.