I cannot quite remember what the problem was, but it had something to with Iterators not returning all objects or Collections being returned containing no objects, but that’s better left for another time at the moment.
Aha, this "smells" like objects of class OJBIterator returned when using PB-API and report-queries or iterating Collections that are using proxy objects in OJB.
In OJB 1.0.x the API will specify Iterator as return type so you have to do a somewhat ugly cast to (OJBIterator) and call #releaseDbResources() if you want to free resources from unexhausted [*] iterators before #finalize() and auto-release.
[*] You can also "exhaust" the iterator by always iterating to the end, which will also trigger a fast release of any DB-resources (including ResultSet and thus implicitly Connection) when the iterator reaches the end.
It could be because of constructs like:
while (ojbiter.hasNext()) {
ojbiter.next();
if (condition) {
break out; <== late release, did not exhaust iterator
}
}Or: ojbiter = broker.getReportQueryIteratorByCriteria(crit); Object onlyOneExpected = ojbiter.next(); // late release, did not exhaust iterator
If you are using Oracle it should become obvious very fast if you have delayed release of resources in some Iterator objects, as this will keep the Oracle server-side cursors allocated and you will very fast get an SQLException with MAX_CURSORS_EXCEEDED.
Any more suggestions?
You could also try using the abandoned-config in DBCP and set a very short threshold time to log connection leaks, although it's difficult to say what the threshold should be if you really want to hold on to some connections a bit longer.
Regards, Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
