Turns out that this is not really a JBoss issue, but a Hibernate issue. It looks like the 'AbstractBatcher' class in Hibernate is not quite set up correctly to handle batch updates. We changed the following method in this class to fix this issue:
Code:
public boolean hasOpenResources() {
//return resultSetsToClose.size() > 0 || statementsToClose.size() > 0;
return resultSetsToClose.size() > 0 || statementsToClose.size() > 0 || (batchUpdate != null);
}
When a connection is closed, this method is used to check if there are any open resources. In batch update mode, Hibernate doesn't use the 'resultSetsToClose' & 'statementsToClose' variables; but uses the 'batchUpdate' variable. As such, this method needs to return 'true' if batch update is in process.
As for, why this worked in Weblogic and not in JBoss, my only explanation is that JBoss does a better job of cleaning resources after the connection is closed than Weblogic does.
It seems like, when a connection is closed, JBoss closes all the associated PreparedStatements; but Weblogic keeps them open. In this particular case, it seems like, Weblogic was re-attaching a connection to the old PreparedStatement.
Hope this all makes sense. Can someone from the Hibernate team tell me if this is indeed a bug? Is there a better way to fix it? Your help will be appreciated. Thanks.
Login
FAQ
Search