Prevent further configuration once AbstractJdbcCall is compiled

[dssievewright]

During profiling of our application, we noticed a potential memory leak. We had a SimpleJdbcCall object as a field in a DAO. Typically, we would create and initialize this object during the PostConstruct phase and runtime would just need to set up the inputs and call execute. However the developer accidentally put the declareParameters in the same method as execution so those paremeters kept getting added.

Example DAO:

@Resource
private JdbcTemplate jdbcTemplate;

private SimpleJdbcCall procedure;

@PostConstruct
void buildProcedure() {
  procedure = new SimpleJdbcCall(jdbcTemplate).withProcedureName("some_procedure");
}

void executeProcedure(String input) {
  procedure.declareParameters(new SqlParameter("param", Types.VARCHAR));
  procedure.execute(Collections.singletonMap("param", input));
}

The first time executeProcedure is called, the procedure gets compiled and all the parameters get set in the callMetaDataContext. Subsequent calls to declareParameters do not alter the callMetaDataContext and the procedure executes successfully.

The problem: Each time declareParameters is called, that parameter gets added to declaredParameters in AbstractJdbcCall where it will sit there, never gets used, and never gets released for garbage collection.

This proposed solution here is to check to see if the call has been compiled before adding to the declaredParameters list. If the call is not compiled, we'll proceed as normal. Otherwise, AbstractJdbcCall will ignore the request because the parameter won't be added to the callMetaDataContext.

[snicoll]

@dssievewright thanks for the PR.

The problem: Each time declareParameters is called, that parameter gets added to declaredParameters in AbstractJdbcCall where it will sit there, never gets used, and never gets released for garbage collection.

I can see that but the memory leak is in the use of the class, not the class itself. Rather than ignoring the call (which looks odd to me), I'd rather throw an exception since it wouldn't change the state of the object anyway. What do you think @jhoeller?