closeWithKey in Oracle 10g

closeWithKey is Oracle's own method call for explicit caching. I think explicit cache itself is an over-engineering,why do we need explicit caching when there is already implicit caching? Anyways, the company I work with used it in legacy code. It works fine, well, sort of. There are some bugs in application side mainly mainly associated with not using bind variable. Both implicit caching and explicit caching means you mark the statement as eligible to be close, i.e, if there are more sqls(primarily because not using bind variable) than the cache can hold, then some statements will have to aged out based on LRU algorithm. Unfortunately, our app code uses it in a way like:
p = prepareStatement
rs=executeQuery();
p.closeWithKey();

while(rs.next())
...

This itself is flawed because during the time of fetching, i.e rs.next()), if there are more sqls than cache size need to be cached, then p will be aged out, rs.next() will get a "closed statement" sql exception. If the fetch phase is short such as one row in the resultset and the while loop doesn't call sql , then it is unlikely the "closed statement" would occur.

But all this has changed in 10g JDBC. in 10g, if you call closeWithKey, not sure about the plain close() call for implicit caching but should be same, the statement is marked close immediately, in order to open it you have to call prepareStatementWithKey, though the second prepare doesn't incur a (soft) parse. Therefore, the previous code will fail immediately with "closed statement" exception.