Re: [Springframework-developer] JdbcOperationsCallback

[<jue...@we...>]

We already have a StatementCallback and a PreparedStatementCallback, for =
example, letting you execute the same Statement object multiple times or =
whatever you want to do with it. User code is just responsible for =
closing ResultSets in that case.
=20
I've considered adding a ConnectionCallback before, passing a managed =
Connection object in and converting all SQLExceptions. User code would =
then be responsible for closing Statements and ResultSets accordingly. I =
wouldn't mind adding such a callback.
=20
However, a plain callback that just converts SQLExceptions doesn't =
really fit into JdbcTemplate, because there's no resource managed there. =
JdbcTemplate wouldn't do anything here; all that's needed is a =
SQLExceptionTranslator. Therefore, it's probably cleaner to use a =
try/catch block and delegate to a SQLExceptionTranslator when catching a =
SQLException. The translator could come from a bean property of type =
SQLExceptionTranslator, or from =
getJdbcTemplate().getExceptionTranslator() in a JdbcDaoSupport subclass.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 03.12.2004 14:16
An: spr...@li...
Betreff: Re: [Springframework-developer] JdbcOperationsCallback



Sure, the whole point is that this is not something you are going to use
given the choice to use other methods on the template, but mainly when
you need to wrap existing code which throws SQLException. In the
particular case I needed yesterday, I actually also needed to pass a
connection to the other code. There could be a variant which gets a
connection for you, for this sort of case.   I don't like the
possibility that people will now use this sort of method to write
old-style code which doesn't clean up resources properly, as you
mention, but on the other hand, if we document it well it will hopefully
be helpful for these kinds of situations. In this case, I ended up
having to manage the connection myself, and had to wrap to catch SQL
exceptions, etc....

Colin


Thomas Risberg wrote:

> The only drawback that I can think of is that now you are responsible
> for closing any statements/resultsets that you open - you need to
> provide a try/finally block within the callback to properly close them
> in case of an exception being thrown.  As long as we document this, we
> should be OK.
>
> Thomas
>
> Colin Sampaleanu wrote:
>
>> Does anybody think it doesn't make sense to add a
>> JdbcOperationsCallback interface, similar to some of the other
>> callbacks, which can be used via a new
>>   jdbcTemplate.execute(JdbcOperationsCallback)
>> method? This could be used to wrap arbitrary code which throws SQL
>> exceptions, so that they are properly mapped. I've had a need for
>> something like this a few times...
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer