Core Spring 4.2 Study Guide answers (part 3: JDBC, transactions and ORM)

Checked exceptions are exceptions that are checked at compile time – that fact enforces the developer to either catch it and handle or declare as being thrown and it will be propagated in call stack. Unchecked exceptions are not checked at compile time.

Spring prefers unchecked exception because this way it gives the developer possibility to choose to handle them or not –  he is not enforced to handle them. To use Spring specific exceptions you must use Spring templates. JdbcTemplate takes care of transforming SQLExceptions to meaningful DataAccessExceptions, this is done using SQLExceptionTranslators.

Spring DataAccessExceptions are divided in 4 types:

1. NonTransientDataAccessException – you must fix the cause of fail and trying will succeed
2. TransientDataAccessException – no action is required for retry to succeed (timeout etc.)
3. RecoverableDataAccessException – may succeed if app performs some recovery steps and retries the entire transaction
4. ScriptException – when initializing a test database using a bean of type DataSourceInitializer fails because of some SQL script error.

DataSource is a generalized connection factory. It hides connection pooling and transaction management from application code. Spring obtains connection to the database through a DataSource.

With Spring you can configure different types of DataSources:

• JDBC-driver defined DataSources
• JNDI DataSources
• Connection-pooling DataSources 

JDBC driver-based DataSources are the simples type. Spring has 3 types of them:

1. DriverManagerDataSource
2. SimpleDriverDataSource
3. SingleConnectionDataSource

You configure one as follows:

@Bean
public DataSource datasource(){
DriverManagerDataSource ds = new DriverManagerDataSource();
ds.setDriverClassName("org.h2.Driver"); //this is a in-memory DB
ds.setUrl("jdbc:h2:tcp://localhost/~/databaseName");
ds.setUsername("admin");
ds.setPassword("pass");
return ds;
}

Connection-pooling DataSources are configured the same way but you may pass some parameters related to the connections pool too.

As for JNDI you can use the jee namespace for XML:

<jee:jndi-lookup id="dbDataSource"
   jndi-name="jdbc/DatabaseName"
   expected-type="javax.sql.DataSource" />

or in case you use Java config:

 @Bean
 public DataSource dataSource() {
 final JndiDataSourceLookup dsLookup = new JndiDataSourceLookup();
 dsLookup.setResourceRef(true);
 DataSource dataSource = dsLookup.getDataSource("jdbc/yourJdbcGoesHere");
 return dataSource;
 }

or a more generic way (as this can be used to lookup any type of object from JNDI)… this will return a factory that in its turn will inject DataSources in places it is required:

@Bean
public JndiObjectFactoryBean dataSource() { //it returns a factory that will return DataSources when required
JndiObjectFactoryBean jndiObjectFB = new JndiObjectFactoryBean();
jndiObjectFB.setJndiName("jdbc/SpittrDS");
jndiObjectFB.setResourceRef(true);
jndiObjectFB.setProxyInterface(javax.sql.DataSource.class);
return jndiObjectFB;
}

A very important DataSource implementation for development/testing purposes is the embedded data source. It runs as part of application instead of being a standalone element. In XML we use jdbc namespace for configuring an in-memory (embedded) database. You specify the SQL DDL (Data Definition Language) and DML (Data Manipulation Language) scripts while declaring the embedded data source.

<jdbc:embedded-database id="dataSource" type="H2"> <!-- instead of H2 you may set DERBY - for using an Apache Derby db -->
<jdbc:script location="blog/codingideas/db/schema.sql"/> <!-- DDL, you may add more of these -->
<jdbc:script location="blog/codingideas/db/data.sql"/> <!-- DML, you may add more of these -->
</jdbc:embedded-database>

jdbc:embedded-database does 2 things: adds an embedded database and exposes a DataSource (whose name is specified using the id attribute).

You can do the same using Java:

@Bean
public DataSource dataSource() {
return new EmbeddedDatabaseBuilder()
.setType(EmbeddedDatabaseType.H2)
.addScript("classpath:schema.sql")
.addScript("classpath:data.sql")
.build();
}

Although I presume that this question wants to say that JdbcTemplate uses “template method” design pattern – I think that is wrong, as the abstract class it extends doesn’t conform to the structure of the abstract class required for the template method design pattern. Template method design pattern is about the following: you have an abstract class that has one final non-abstract method that defines some algorithm and more abstract methods that are to be implemented in the child classes. And when you run the final method (that you get from the abstract class) you get the algorithm defined in the abstract class but the implementation is done in the child non-abstract class. Meanwhile our JdbcAccessor class that is abstract and is the parent class for JdbcTemplate has no such a method that is final and defines some algorithm.

JdbcTemplate is a convenience class that hides a lot of JDBC boilerplate code and allows to:

• execute SQL queries
• execute update statement
• performs stored procedures calls
• iterates over ResultSets
• extracts returned parameter values

As Wikipedia states:

a callback is any executable code that is passed as an argument to other code, which is expected to call back(execute) the argument at a given time

In our case we have some interfaces (callback interfaces) that you build some anonymous classes on and pass those classes to methods of JdbcTemplate. 

JdbcTemplate 3 central callback interfaces:

• RowCallbackHandler – An interface used by JdbcTemplate for processing rows of a ResultSet on a per-row basis
• CallableStatementCreator – One of the three central callback interfaces used by the JdbcTemplate class. This interface creates a CallableStatement given a connection, provided by the JdbcTemplate class.
• PreparedStatementCreator – One of the two central callback interfaces used by the JdbcTemplate class. This interface creates a PreparedStatement given a connection, provided by the JdbcTemplate class.

Others:

• ResultSetExtractor
• BatchPreparedStatementSetter – Batch update callback interface used by the JdbcTemplate class. This interface sets values on a PreparedStatement provided by the JdbcTemplate class
• ParameterizedPreparedStatementSetter – Parameterized callback interface used by the JdbcTemplate class for batch updates. This interface sets values on a PreparedStatement provided by the JdbcTemplate class.
• PreparedStatementCallback – Generic callback interface for code that operates on a PreparedStatement
• StatementCallback – Generic callback interface for code that operates on a JDBC Statement
• CallableStatementCallback – Generic callback interface for code that operates on a CallableStatement
• ResultSetExtractor – Callback interface used by JdbcTemplate’s query methods.
• PreparedStatementSetter – General callback interface used by the JdbcTemplate class. This interface sets values on a PreparedStatement provided by the JdbcTemplate class.

Yes, using execute() methods – one of them accepts StatementCallback objects and the other wraps the String you pass in a StatementCallback. StatementCallback in its turn has a doInStatement() method that accepts Statement objects. So you can pass either an anonymous class with overridden doInStatement() method or just a simple String that execute() method of Statement will be run on.

Here’s a rather ugly example:

template.execute(new StatementCallback<ResultSet>() {
    public ResultSet doInStatement(Statement statement) throws SQLException, DataAccessException {
        ResultSet rs = statement.executeQuery("SELECT * FROM databaseTable");
        RowCallbackHandler handler = new RowCallbackHandler() {
            public void processRow(ResultSet resultSet) throws SQLException {
                while (resultSet.next()) {
                    System.out.println(resultSet.getObject(1) + "," + resultSet.getObject(3));
                }
            }
        };
        handler.processRow(rs);
        return rs;
    }
});

Yes. Connection in acquired by:

Connection con = DataSourceUtils.getConnection(getDataSource());

and released by:

DataSourceUtils.releaseConnection(con, getDataSource());

from:

public <T> T execute(PreparedStatementCreator psc, PreparedStatementCallback<T> action)
      throws DataAccessException

If you define a method as @Transactional and internally add some JdbcTemplate code it will run in that transaction; but JdbcTemplate itself cannot manage transactions – that is job of TransactionTemplate.

Transaction is an indivisible unit of work. 

Transactions are described in terms of ACID properties, which are as follows:

• Atomic: all changes to the database made in a transaction are rolled back if any change fails.
• Consistent: the effects of a transaction take the database from one consistent state to another consistent state.
• Isolated: the intermediate steps in a transaction are not visible to other users of the database.
• Durable: when a transaction is completed (committed or rolled back), its effects persist in the database.

In short a local transaction is a simple transaction that is about one single database; whilst a global one is application server managed and spreads across many components/ technologies. For global transactions consider the case that a record must be persisted in a database ONLY if some message is sent to a queue and processed – if the later fail the transaction must be rolled back.

Yes as it can affect many components. The core concept in Spring transactions world is the transaction strategy that is defined by PlatformTransactionManager. This interface is a service provider interface. It has multiple implementations and the one you choose depends on your requirements. From PlatformTransactionManager through getTransaction() method – by passing the TransactionDefinition in, you get the TransactionStatus that may represent a new or an existing transaction.

TransactionStatus specifies:

• isolation
• propagation
• propagation 
• read-only status 

of the transaction to be looked up in the PlatformTransactionManager.

You can define transactions in 2 ways:

1. Declarative way 
2. Programmatic way

Declarative way deals with adding some AOP related to transactions to the methods annotated with @Transactional or that have some tx-advices defined by XML.

Programmatic way is about using either TransactionTemplate or directly PlatformTransactionManager.

Rather than using XML AOP for matching the methods that should be transactional you can add this (@Transactional) annotation. PlatformTransactionManager is an interface that defines the transaction strategy through different implementations that match requirements specific to the project they are used in.

TransactionTemplate is a class that uses callback methods for executing some operations in a transaction. That is achieved by anonymous classes build on TransactionCallback callback interface. 

You may choose to use TransactionTemplate in case you have a small number of transactional methods in your project. 

Transaction isolation level is the level of one isolation of one transaction from another. Transaction level is defined from perspective of 3 characteristics:

1. Dirty reads – one transaction can read uncommitted data from other transaction
2. Non-repeatable read – occurs when a second transactions reads the same row from first transaction at different times getting different data each time because of first transaction committing some changes or deleting the row.
3. Phantom reads – occurs when the same search criteria is returning different data because of some other transaction interfering and deleting/adding data.

In Spring we have the following isolation levels:

• int ISOLATION_DEFAULT = -1 – Use the default isolation level of the underlying datastore.
• int ISOLATION_READ_UNCOMMITTED = 1 – Indicates that dirty reads, non-repeatable reads and phantom reads can occur.
• int ISOLATION_READ_COMMITTED = 2 – Indicates that dirty reads are prevented; non-repeatable reads and phantom reads can occur.
• int ISOLATION_REPEATABLE_READ = 4 – Indicates that dirty reads and non-repeatable reads are prevented; phantom reads can occur.
• int ISOLATION_SERIALIZABLE = 8 – Indicates that dirty reads, non-repeatable reads and phantom reads are prevented.

<tx:annotation-driven/> is hard-wired to look for a bean called transactionManager while @EnableTransactionManagement will look for PlatformTransactionManager by type – any bean name will be ok.

JdbcTemplate supports querying for any type of object assuming you supplied a RowMapper interface implementation defining the way database table should be mapped to some entity type.

It has many overloaded methods for querying the database but mainly you can divide them in:

1. query()
2. queryForObject() – if you are expecting only one object
3. queryForMap() – will return a map containing each column value as key(column name)/value(value itself) pairs.
4. queryForList() – a list of above if you’re expecting more results 

Transaction propagation defines whether current transaction will be extended or not.

There is an Enum that specifies the list of all possible propagation types – org.springframework.transaction.annotation.Propagation:

Since transaction-management is implemented using AOP @Transactional annotation will have no effect on the method being called as no proxy is created. The same behavior is characteristic for AOP aspects.

If we check the API we can see the following:

@Target(value={METHOD,TYPE}) //METHOD is for methods and TYPE is for one of the following: class, interface, enum
 @Retention(value=RUNTIME)
 @Inherited
 @Documented
public @interface Transactional

If you put @Transactional at class-level this is equal to annotating each method of that class.

Declarative transaction management is a model build on AOP. Spring has some transactional aspects that may be used to advise methods for them to work in a transactional manner.

Any RuntimeException (unchecked exception) or Error will cause by default a rollback. Checked exceptions don’t cause a rollback. You can specify 2 different attributes for tx:method in cause you want to rollback or to not rollback for certain exception (no matter it is checked or unchecked):

1. rollback-for
2. no-rollback-for

That was for the declarative way. In case you want to set current transaction as “rollback only” you can do that programmatically too:

 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

@Transactional too has some parameters for changing the default behaviour:

• rollbackFor
• noRollbackFor
• rollbackForClassName
• noRollbackForClassName

Test transactions will be automatically rolled back after completion of the test.

JDBC AutoCommit will treat each individual SQL statement as a transaction. This means that if logically or from business point of view you need to make sure some statement is ok before executing another one, it would fail. Transactions are meant to solve this problem by “grouping” operations in some logical way so that you confirm to ACID principle (Atomicity, Consistency, Isolation, Durability). 

JPA stands for Java Persistence API. ORM – Object Relational Mapping. The idea behind ORM is that in applications we deal with objects and classes whilst in databases we have to do with tables and rows. ORM is meant to help us map our entities to the database tables.

PersistenceContext is a set of entity instances that correspond to persistent entity identity. All the manipulations with the persistent instances are made using EntityManager. EntityManager writes, deletes and searches entities to database.

@Entity annotation is used to mark a class as an entity class that will be mapped to the database using ORM.

Because JPA has 2 types of entity managers Spring also has functionality to work with those 2 types.

Here I am talking about:

1. Application-managed entity managers (produced by LocalEntityManagerFactoryBean of Spring)
2. Container-managed entity managers (produced by LocalContainerEntityManagerFactoryBean)

It is preferably to use the container-managed type because in this case you will not need the persistence.xml file (located in META-INF) and also it allows for scanning packages for @Entity-annotated classes (using setPackagesToScan() of LocalContainerEntityManagerFactoryBean). 

For the container-managed entity managers there may be an additional source – JNDI. you can get such entity managers in 2 ways:

1. XML:

   <jee:jndi-lookup id="emf" jndi-name="persistence/spitterPU" />

2. Java:

   @Bean
   public JndiObjectFactoryBean entityManagerFactory() {}
   JndiObjectFactoryBean jndiObjectFB = new JndiObjectFactoryBean();
   jndiObjectFB.setJndiName("jdbc/SpittrDS");
   return jndiObjectFB;
   }

Important to mention:
Although the Java method doesn’t return an EntityManagerFactory, JndiObjectFactoryBean does. 

Excerpt from Spring documentation:

Spring JPA also allows a configured JpaTransactionManager to expose a JPA transaction to JDBC access code that accesses the same DataSource, provided that the registered JpaDialect supports retrieval of the underlying JDBC Connection. Out of the box, Spring provides dialects for the EclipseLink, Hibernate and OpenJPA JPA implementations. See the next section for details on the JpaDialect mechanism.

Please check https://stackoverflow.com/questions/2673678/what-transaction-manager-should-i-use-for-jbdc-template-when-using-jpa 

PlatformTransactionManager is the central piece in Spring transactions management.

PlatformTransactionManager returns a TransactionStatus when you pass a TransactionDefinition to its getTransaction() method.  In TransactionDefinition that is passed we can specify different transaction characteristics like isolation, propagation and timeout.

@PersistenceContext expresses a dependency on a container-managed Entity Manager and its associated persistence context. It does NOT inject an EntityManager – it makes a proxy to the required EntityManager for taking care of correct transaction management and thread-safety.

An instant repository is a repository resulting from extending some class representing an implementation of Repository interface (for example JpaRepository) or annotating some class with @RepositoryDefinition. 

You have 2 options:

1. Extend some implementation of Repository interface.
2. Annotate the future instant repository class with @RepositoryDefinition

Spring @Query annotation is used for customize methods of some instant repository.

@Query("select p from Person u where p.name like %?1%")
List<Person> findAllByName(String name);

@Query("select p from Person p where p.name= :n")
Person findOneByName(@Param("n") String name);
@Query("select p.name from Person p where p.id= :id")
String findNameById(Long id);