Additional Considerations

There are still some issues that you will have to consider before you can successfully implement a JDBC- based solution using Spring's JDBC abstraction framework.

Performance

So how does Spring's JdbcTemplate with all of its callback methods perform? Compared to using straight JDBC, we have not found any difference that is worth noting when executing queries and regular updates. This is not that surprising because we would expect object creation, query execution, and the transfer of the serialized data to take most of the processing time. A few extra callbacks are not going to impact this very much. This includes the RDBMS Operation classes that perform queries and updates.

One area where there is a slight performance penalty is with the batch updates. This is because we create new objects that we hold on to for the entire batch, and then write them all at once when the batch is flushed. Doing it this way limits the time we have to keep the connection to the database open, but it incurs a slight performance penalty. However, we have seen Spring JDBC batch updates used in extreme situations (one million updates per transaction) and showing excellent performance.

Another item to note for performance tuning: If you are retrieving a large number of rows, you can change the number of rows that the JDBC driver will fetch from the database when more rows are needed. This cuts down on the number of roundtrips that are made to the database:

JdbcTemplate jt = new JdbcTemplate(ds);  jt.setFetchSize(100);

You just have to be careful not to set it too high, or you might run out of memory.

When to Use JDBC Versus O/R Mapping

What are the factors that determine when you choose different data access technologies? Let's first assume that the database solution is limited to a relational database. The access choices would then be straight JDBC, Spring's JDBC framework, TopLink, iBATIS, and Hibernate or JDO. The straight JDBC solution would, in our opinion, be the solution of choice only when you are not allowed to use any framework besides what is delivered in J2SE or J2EE.

If your project has only a few persistent classes or you have to map to an existing database with several stored procedures, then a Spring JDBC solution makes sense. There is very little to configure and if you have only a few classes to map to a Java class, then the MappingSQLQuery makes mapping straightforward. The StoredProcedure class makes working with stored procedures easy.

If you have many classes that map to an existing database or you don't have control over the database design, then you have to look at the mapping options between the tables and your Java classes. If the mapping is mostly one table per Java class, then Hibernate or JDO makes for a good option. If you have a group of tables mapping to a single Java class, you will have an easier time mapping using iBATIS SQL Maps. Both iBATIS and Hibernate/JDO will allow you to use Spring's JDBC layer for the few instances where the mapping is not appropriate, or where you have to use stored procedures for interacting with the database. In most applications with complex persistence requirements using an ORM tool, there will be corner cases that are best addressed using an SQL-oriented approach.

JDBC Versions and J2EE Versions

One issue you face when using an application framework combined with an application server is the supported version of various APIs. The J2EE specification that is currently supported by the majority of application servers is J2EE 1.3. The JDBC specification that is part of this specification is JDBC 2.1. There is now a JDBC 3.0 specification that is part of J2SE 1.4 and J2EE 1.4, but it is not yet widely supported by application servers and also not fully supported by most database vendors.

The Spring JDBC support is based on the JDBC 2.1 specification, which means that you can use almost all the features of Spring's JDBC support in older application servers. The option to retrieve generated keys and RowSet support are the two features that do require JDBC 3.0 support.