[hibernate-dev] JdbcSession proposal

[Steve Ebersole]

On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:

>
> It would be nice to make the return value generic:
>
> public T accept(PreparedStatementQueryOperation operation, Class<T> 
> resultClass);


95 times out of 100 inside Hibernate code we really can't take advantage 
of the parameterized type. So its less important in my mind. Like I said 
earlier, the intent here is not to build a general purpose JDBC 
abstraction library.

But if you look at Operation you can see it is parameterized 
(Operation<T>) and that accept() leverages that:

public <T> T accept(Operation<T> operation);


>
> I can see the merit of breaking out 
> PreparedStatementQueryOperation.getStatementPreparer(), 
> getStatementExecutor().execute(), and 
> getResultSetProcessor().extractResults(), as opposed to 
> PreparedStatementQueryOperation.prepare(), execute(), extractResults().
>
> I think there should also be a 
> PreparedStatementQueryOperation.getStatementBinder() returning a 
> StatementBinder, since it's really a step that is separate from preparing.


Yep, I contemplated the same.

>
> In the case where operation.holdOpenResources() == true, which object 
> would hold the open resources? If it's JdbcSession that manages them, 
> there would also need to be JdbcSession.closeResources( operation ); 
> otherwise, something like 
> PreparedStatementQueryOperation.closeResources() would be needed.

Its the ResourceRegistry which in the actual code.  It does not segment 
resources by the operation they come from atm.  The only thing it x-refs 
is Statement->ResultSets.  I am not sure it is worth the overhead to do 
this segmenting either.

But you are correct, if we did segment these registered resources by 
operation we would need a level of releasing them by operation too.