The RowCallbackHandler interface extracts values from each row of a ResultSet.

Has one method – processRow(ResultSet)
Called for each row in ResultSet.
Typically stateful.

 
 

SQLProvider:

Has one method – getSql()
Typically implemented by PreparedStatementCreator implementers.
Useful for debugging.

 
 

PreparedStatementCreator:

Is one of the most common used interfaces for writing data to database.
Has one method – createPreparedStatement(Connection)
Responsible for creating a PreparedStatement.
Does not need to handle SQLExceptions.

 
 

Spring's JdbcTemplate is central class to interact with a database through JDBC. JdbcTemplate provides many convenience methods for doing things such as converting database data into primitives or objects, executing prepared and callable statements, and providing custom database error handling.


JdbcTemplate template = new JdbcTemplate(myDataSource);

 
 

SQLExceptionTranslator, is an interface to be implemented by classes that can translate between SQLExceptions and Spring's own data-access-strategy-agnostic org.springframework.dao.DataAccessException.

 
 

Spring DAO classes throw exceptions which are subclasses of DataAccessException(org.springframework.dao.DataAccessException).Spring provides a convenient translation from technology-specific exceptions like SQLException to its own exception class hierarchy with the DataAccessException as the root exception. These exceptions wrap the original exception.

 
 

The Data Access Object (DAO) support in Spring is aimed at making it easy to work with data access technologies like JDBC, Hibernate or JDO in a consistent way. This allows one to switch between the persistence technologies fairly easily and it also allows one to code without worrying about catching exceptions that are specific to each technology.

 
 

    Programmatic transaction management is usually a good idea only if you have a small number of transactional operations.
On the other hand, if your application has numerous transactional operations, declarative transaction management is usually worthwhile. It keeps transaction management out of business logic, and is not difficult to configure.

 
 

The basic approach is similar: it is possible to specify transaction behavior (or lack of it) down to individual method level. It is
    possible to make a setRollbackOnly() call within a transaction context if necessary. The differences are:

Unlike EJB CMT, which is tied to JTA, the Spring Framework's declarative transaction management works in any environment. It can work with JDBC, JDO, Hibernate or other transactions under the covers, with configuration changes only.


The Spring Framework enables declarative transaction management to be applied to any class, not merely special classes such as EJBs.


The Spring Framework offers declarative rollback rules: this is a feature with no EJB equivalent. Both programmatic and declarative support for rollback rules is provided.


The Spring Framework gives you an opportunity to customize transactional behavior, using AOP. With EJB CMT, you have no way to influence the container's transaction management other than setRollbackOnly().


The Spring Framework does not support propagation of transaction contexts across remote calls, as do high-end application servers.

 
 

Most users of the Spring Framework choose declarative transaction management because it is the option with the least impact on application code, and hence is most consistent with the ideals of a non-invasive lightweight container