Spring and JDBC

I decided to implement the IPersonDAO interface to work with JDBC.

public class SimplePersonDAO extends SimpleJdbcDaoSupport implements IPersonDAO {
    private static final Logger logger = Logger.getLogger(PersonDAO.class);
//remaining methods
}

Spring and Database - the cool stuff - 2

In the previous post we saw that Spring gave us a generic way to handle Data access exceptions. The next goodie from the Spring box is the ability to ignore the database access code and focus on the actual database logic.

Spring and Database - the cool stuff

Spring gives us some real cool advantages when integrating with databases. Theses advantages are applicable whether you connect to the database via JDBC or via frameworks.

Spring And The Actual DB Operations

In the last few posts we saw how we could use Spring to create data-sources to interact with the databases. However we never wrote any code to actually do anything in the database. Spring as discussed earlier provides integration via direct JDBC and also via ORM frameworks. We shall start by investigating Spring's JDBC integration mechanism.

Pooled Data-sources and Spring -2

In the previous post we saw how Spring integrated with DBCP. There is another data-source c3p0 which can also be integrated via Spring.

Pooled Data-sources and Spring

In an earlier post we saw non pooled data-sources. However both DriverManagerDataSource and SingleConnectionDataSource have their own limitations.

Managing Data-sources via Spring

I am yet to work in a project where database connectivity is not required. Spring has covered this area of development too, providing a series of templates and DAOs. In most cases, the techniques provided by Spring need to use a data-source to connect to the database.
I lifted this definition from the IBM site

A data source is associated with a JDBC provider, which supplies the driver
implementation classes that are required for JDBC connectivity with your specific
vendor database. Application components transact directly with the data source
to obtain connection instances to your database. 

The article found in Java blog also covers the concept very well.

fetch = join and the Cartesian Product Problem

When we apply the join fetch strategy, the data is fetched using joins. We saw this for collections and associations.This leads to a problem when there are multiple collections in the same entity.

fetch = join for non-Collection Association

In the previous post we applied the join fetch strategy for collections. Now I shall apply them to a many-to-one and a one-to-one association.

Property files and @Value

In the previous post we saw how property file values could be used to configure our beans in the XML files. Spring has also come up with annotations to allows us to configure our bean's properties via code:

Using Spring's property-placeholder

With Spring it becomes necessary to configure our beans. This at times involves setting sensitive information in our XML files. In case of database connectivity it would be a username or password. People are not comfortable with this kind of details being available in their war files.

Publishing Events asynchronously

In the previous post we saw how Spring's ApplicationContext provided for event publishing and listening. The default listener that Spring implements is synchronous. The publish method will wait until the methods of all the listeners have completed successfully. This kind of blocking behaviour may not be suitable for all scenarios.

fetch = join for Collection

There could be a scenario wherein we need an association to be always available whenever an Entity is loaded. In this case the additional select queries that are fired are a performance loss. We could tell Hibernate to fetch the entity and the association in a single call to the database.

fetch = subselect

We have seen that the default fetch strategy for lazy Collections can result in an N+1 problem. We saw how to improve this using the batch size setting. Here also however the query count can end up being a little high.
Hibernate also allows all the Collections to be retrieved in a single query when a single collection is accessed. Thus as opposed to a reduced query count that we get via batching, in this case it is exactly 1 additional query.

batch-size =n

In our previous example we saw how a default fetch strategy(fetch = "select") could result in N+1 selection problem for Hibernate Associations. One way to solve this problem would be to use batch-size property