| I think I found the root cause. If thats the correct fix then let me know next steps. Issue found in Hibernate-Core-4.3.10-Final::-
1. org.hibernate.result.internal.OutputsImpl has 1 ISSUE public List processResultSet(ResultSet resultSet) throws SQLException {
if(this.needsDiscovery) { // once the first resultset is read it’s no more discovering the columns of next resultset super.autoDiscoverTypes(resultSet); this.needsDiscovery = false; } return super.processResultSet(resultSet, this.queryParameters, this.session, true, (ResultTransformer)null, 2147483647, Collections.emptyList());
}
2. org.hibernate.loader.custom.ResultRowProcessor has 1 ISSUE
public void prepareForAutoDiscovery(JdbcResultMetadata metadata) throws SQLException {
if(this.columnProcessors == null || this.columnProcessors.length == 0) {
int columns = metadata.getColumnCount();
this.columnProcessors = new ResultColumnProcessor[columns]; for(int i = 1; i <= columns; ++i) { this.columnProcessors[i - 1] = new ScalarResultColumnProcessor(i); } } } 3. During the first ResultSet, this.needsDiscovery is set to false in #1. Further, in #2, the columnProcessors.length is set to number of columns of 1st result set.
Now, when I call StoredProcedureQuery.hasMoreResults() to know and then access 2nd resultset, it calls #1. But this.needsDiscovery is already set to false. So, supert.autoDiscoverTypes(resultSet) is NEVER called.
If we set that to false forcibly then it calls #2. But this.columnProcessor is already non-null with length = number of columns of first resultset. So setting it to null (& or removing that check) solved the issue. |