boolean closeAndRemoveResourcesInSet(Set s, Method closeMethod) {
boolean okay = true;
Set temp;
synchronized (s) {
temp = new HashSet(s);
}
for (Iterator ii = temp.iterator(); ii.hasNext(); ) {
Object rsrc = ii.next();
try {
closeMethod.invoke(rsrc, CLOSE_ARGS);
} catch (Exception e) {
Throwable t = e;
if (t instanceof InvocationTargetException)
t = ((InvocationTargetException) e).getTargetException();
logger.log(MLevel.WARNING, "An exception occurred while cleaning up a resource.", t);
// t.printStackTrace();
okay = false;
} finally {
s.remove(rsrc);
}
}
// We had to abandon the idea of simply iterating over s directly, because
// our resource close methods sometimes try to remove the resource from
// its parent Set. This is important (when the user closes the resources
// directly), but leads to ConcurrenModificationExceptions while we are
// iterating over the Set to close. So, now we iterate over a copy, but remove
// from the original Set. Since removal is idempotent, it don't matter if
// the close method already provoked a remove. Sucks that we have to copy
// the set though.
//
// Original (direct iteration) version:
//
// synchronized (s)
// {
// for (Iterator ii = s.iterator(); ii.hasNext(); )
// {
// Object rsrc = ii.next();
// try
// { closeMethod.invoke(rsrc, CLOSE_ARGS); }
// catch (Exception e)
// {
// Throwable t = e;
// if (t instanceof InvocationTargetException)
// t = ((InvocationTargetException) e).getTargetException();
// t.printStackTrace();
// okay = false;
// }
// finally
// { ii.remove(); }
// }
// }
return okay;
}
boolean closeAndRemoveResultSets(Set rsSet) {
boolean okay = true;
synchronized (rsSet) {
for (Iterator ii = rsSet.iterator(); ii.hasNext(); ) {
ResultSet rs = (ResultSet) ii.next();
try {
rs.close();
} catch (SQLException e) {
if (Debug.DEBUG)
logger.log(MLevel.WARNING, "An exception occurred while cleaning up a ResultSet.", e);
// e.printStackTrace();
okay = false;
} finally {
ii.remove();
}
}
}
return okay;
}