Spring Recipes covers Spring 2.5 (and earlier versions) taking it from the simplest concepts right through to the most advanced level. The book is divided into nineteen chapters organised into three parts; Core, Fundamentals and Advanced. Each part builds on the previous ones to grow your understanding of all aspects of the Spring framework, for this reason the book is best read cover to cover.

This book is in no way filler and is packed full of content covering not only the Spring framework and but also several common Spring projects including; Spring Security, Spring Web Flow and Spring Web Services. For anyone that knows Spring (and it’s associated projects), this is a huge amount of information to cover in just one book, but this book really does deliver!

As the author puts it; “Reading Spring Recipes will help you master the most important 80 percent of Spring’s features with just 20 percent of the effort you would need to learn them all.” If you are already using Spring, this book will serve as an invaluable reference and companion guide for future development. If you are a newcomer to Spring, this book will serve as an excellent launch pad to get you up, running and productive with Spring very quickly.

Structure

Each of the recipes covered in the book follows; a problem, solution and then how it works approach. This approach lays out many of the common FAQ style questions that come up on Spring Forum in an accessible way; clearly outlining the problem and mapping the path to the solution. This book also acts an excellent companion to the Spring Reference manual, which is sometimes difficult to read in places and lacks the array of examples this book provides.

Audience

The intended audience for Spring Recipes, is any Java programmer hoping to learn more about Spring. No prior knowledge of Spring is required as this book covers it all right from core concepts such as inversion of control (or Ioc). This book is accessible to anyone who has heard the hype about Spring and simply wants to learn more about it and how they can leverage it’s power. This book gives Java developers hands-on experience using the Spring framework with real-world examples, this experience can be transferred straight into your Spring project.

Chapters

Part 1: Core

This part focuses on the core concepts and mechanisms of the Spring framework. The chapters in this part aim to familiarize you with Spring’s core. As a newcomer to Spring Chapter 1 introduces the concept of inversion of control the core foundation of Spring. It explains how and IoC container works, but also why it is useful and beneficial to use one. This chapter serves as an excellent introduction to IoC and is invaluable to anyone who isn’t quite sure why they should use a container based approach. This chapter is a must for anyone new to Spring or anyone trying to deliver it to a new audience.

Chapters 2-4 build on the IoC introduction, explaining how to setup and configure a new Spring project and apply the basics of Spring configuration. These first four chapters are the foundation for the rest of the book and are a must read for anyone who has never used Spring before and even advanced users may find useful hints and tips within. Chapters 5-6 cover the extremely powerful approach of AOP, introducing crosscutting concerns and how these can be configured with Spring. This technique can be extremely useful to provide trace logging, caching and other crosscutting concerns such as security. This is a must read for anyone using Spring, even if you are not directly leveraging Spring AOP or AspectJ. Spring AOP lays the foundation for introducing how Spring provides features such as transparent transaction support and method level authorization checking.

Part 2 : Fundamentals

This part has a split focus, it introduces Spring’s Data Access support, Web integration and also Testing support. Chapter 7 introduces one of the most important aspects of Spring’s data access support in the form of JdbcTemplate. This shows the reader how they can use JdbcTemplate to prevent the use of direct JDBC and instead let Spring handle all of the boiler plate code. As JdbcTemplate removes the need for the common try/catch/finally/try/catch code seen with JDBC, the code is much cleaner and much more readable. Along with this support, the Spring DataAccessException hierarchy is introduced which provides a rich set of common exceptions to provide a more granular handling approach.

Chapter 8 introduces Spring’s excellent transaction management support and explains in great detail all of the various propagation behaviours and isolation levels. This chapter is one of my favourites as it not only introduces the concept of Spring transaction support but transactions in general. It’s accessible to everyone and extremely useful when mentoring new developers.

Chapter 9 discusses how to integrate Spring with existing ORM frameworks, making their usage within the application seamless. This provides multiple approaches to integration allowing you to build on existing Spring classes, or completely decouple your classes from Spring removing the need for any Spring imports within your code. Chapters 10-11 discuss Spring’s popular MVC framework and also discuss how many other leading web frameworks can be integrated with a Spring application. As many of the projects I have worked on in the past have used Struts, Chapter 11 was particularly useful to outline all of the options available to use Spring and Struts together.

This part finishes with the introduction of Spring Testing Support, teaching you not only what features Spring has to offer but also how it integrates with popular testing frameworks such as JUnit and TestNG. As the Spring Testing support has been overhauled, it was great that this book covered the TestContextframework, but also legacy test classes to cover older versions of JUnit and TestNG. This chapter helps you leverage not only IoC for your tests but also transaction support, mock testing and also MVC integration testing. This approach enables you to easily decouple your code from your tests, providing first class support for all your testing needs.

Part 3 : Advanced

For anyone that has mastered the first twelve chapters, Chapter 13 is where things start to get really interesting. This chapter is dedicated to one of the most scary Spring projects, namely Spring Security (formerly known as Acegi). Spring Security provides a full range of authentication, authorization and access control options which allow it to secure a standalone Java application or a web-based application. This book focuses on version 2.x onwards which dramatically reduced the size of the required configuration and also its complexity. Spring Security can be a difficult subject to tackle as it’s often hard for developers to understand it’s concepts, but this chapter builds security into the example application in piecemeal steps. This demystifies many of the problematic areas of Spring Security whilst addressing the common problems a new developer might face.

Chapter 14 covers the portlet application development using the Spring Portlet MVC framework, highlighting the portlet-specific features which differ from the standard Spring MVC framework. If you don’t require the portlet features currently within your application, this chapter can safely be skipped as the next one is another gem. Chapter 15 covers the Spring Web Flow framework which addresses the three major pain–points facing web application developers: user interface navigation control, state management, and modularity. Spring Web Flow offers a flow definition language which encapsulates a reusable sequence of steps that can execute in different contexts. This framework is extremely flexible and powerful, but this chapter provides a great introduction into what is a very large subject.

Chapter 16 introduces the remoting integration that Spring provides for various technologies such as RMI, Hessian, Burlap, HTTP Invoker, and Web Services. Having already been familiar with many of these technologies, this chapter provides an excellent insight into how these can be integrated with Spring and how quickly this can be achieved. This chapter concludes with a look at Spring Web Services including how to develop contract-first web services. Chapter 17 discusses how to develop EJB 2.x and 3.0 components with Spring’s EJB support, and how to use Spring’s JMS support to simplify sending, receiving, and listening to JMS messages. This introduces a powerful concept of message-driven POJOsfor those who like the concept of message-driven beans (MDBs) but don’t want the restrictions of an EJB container.

Chapter 18 demonstrates how easily Spring beans can be exported as JMX MBeans with relative ease in comparison to the typical approach. It continues to extend this by providing remote access, auto-detection and notification. This chapter continues by introducing Spring’s email support which removes the reliance on JavaMail specific mail sessions and exceptions. This provides an abstraction which is independent making it easy to switch to another e-mail API. This chapter finishes with a look at the options available for scheduling tasks within the Spring framework, this integrates with the JDK Timer and also Quartz scheduler.

Chapter 19, this part and the book concludes with a look at the various scripting languages that can used with Spring applications including; JRuby, Groovy and BeanShell. One of the most powerful features of using scripts is that any changes made to these can be detected by Spring and thus the beans can be refreshed automatically. This is of great benefit when you wish to avoid the long compile, deploy and test cycles or the application cannot be taken down regularly for maintenance. This chapter demonstrates how scripted beans can be added to your application quickly and simply using Spring.

Summary

This book has undertaken a mammoth task, trying to squeeze Spring and associated projects all into one book. This book is very clearly written, with well-structured, concise examples that get to the heart of the problem without complicating it with unnecessary detail. The examples provide solutions to real world problems instead of taking the form of the simplistic examples found in many other technology books. My only real minor criticism of this book is it’s scope and size. Given the huge undertaking, there are obviously going to be some areas which only provide a minimal amount of information. This should be expected given the vast array of information covered, but there are a range of Apress books which can build on this foundation. I would still give this book five out of five and rate it as one of the best framework specific books I’ve read.

This book should accompany anyone starting their journey with the Spring framework and even seasoned developers. It can take you from knowing nothing about the Spring framework to knowing pretty much everything you need to create a fully functional web application with all the bells and whistles you’d expect. It provides information and examples on numerous integration points with other popular open source frameworks and languages allowing you to truly become a Spring expert. Read it, read it again and keep it on your bookshelf as a solid reference for the Spring framework.

public Iterable<User> allUsers() {
    final String selectUsers = "select users.username, users.email, " +
        "users.last_password_change from users";
    return getJdbcTemplate().query(selectUsers, new Object[] {},
                new ParameterizedRowMapper<User>() {
        public User mapRow(ResultSet resultSet, int rowNumber) throws SQLException {
            String username = resultSet.getString("username");
            String email = resultSet.getString("email");
            Date lastPasswordChange = resultSet.getDate("last_password_change");
            User user = new DefaultUser(username, email, lastPasswordChange);
            addRolesToUser(user);
            return user;
        }
    });
}

private void addRolesToUser(final User user) {
    final String selectUserRoles = "select role_name from user_roles where username = ?";
    getJdbcTemplate().query(selectUserRoles, new Object[] { user.getPrincipalName() },
                new RowCallbackHandler() {
        public void processRow(ResultSet resultSet) throws SQLException {
            String rolename = resultSet.getString("role_name");
            user.addRole(rolename);
        }
    });
}

Reviewing the code we can see one query is executed to retrieve the users, the problem here is for each user another SQL statement needs to be executed to retrieve the roles. If the first query retrieved one user, this would require one additional query to retrieve the roles. If the first query retrieved a hundred users, this would require one hundred additional queries to retrieve the roles. The pattern will always be the same, one query for the users and n queries dependent on the number of users found, thus n + 1. Although this solution is functional, it does result in many unnecessary SQL statements being executed.

select users.username, users.email, users.last_password_change from users;
select role_name from user_roles where username = ?;
select role_name from user_roles where username = ?;
select role_name from user_roles where username = ?;
...

Shared resources are typically the bottleneck in most applications, so expensive or unnecessary SQL should be avoided if possible. As the application attempts to scale, this bottleneck can become extremely problematic and severely inhibit application performance. Fortunately this is a simple solutions to this problem; introducing a join into the query.

public Iterable<User> allUsers() {
    final String selectUsers =
        "select users.username, users.email, users.last_password_change, user_roles.role_name "
            + "from users left join user_roles on (users.username = user_roles.username)";
    final Map<String, User> users = new HashMap<String, User>();
    getJdbcTemplate().query(selectUsers, new Object[] {}, new RowCallbackHandler() {
        public void processRow(ResultSet resultSet) throws SQLException {
            String username = resultSet.getString("username");
            if (!users.containsKey(username)) {
                String email = resultSet.getString("email");
                Date lastPasswordChange = resultSet.getDate("last_password_change");
                User user = new DefaultUser(username, email, lastPasswordChange);
                users.put(username, user);
            }

            String rolename = resultSet.getString("role_name");
            if (!StringUtil.isNull(rolename)) {
                User user = users.get(username);
                user.addRole(rolename);
            }
        }
    });
    return users.values();
}

Although the code and SQL statement are slightly more complex that the original example, it results in much fewer SQL statements being executed. Instead of the n + 1 statements executed in the first example, one statement is executed that fetches all the required data. This typically results in much improved performance and as the numbers scale the improvement in performance can become much more apparent.

select users.username, users.email, users.last_password_change, user_roles.role_name
    from users left join user_roles on (users.username = user_roles.username);

As with all performance optimizations the most important thing is to measure the effect of the improvement. Performance optimizations aren’t always predictable so by taking measurements before and after the change, you can accurately know if you have actually improved the performance (or made it worse). A SQL join may be the most appropriate way of solving a problem such as this, but there are other alternatives such as caching the data instead. Although the SQL n + 1 selects is an extremely common problem, is not always well understood and is often still found within code. It is very easy to introduce a problem like this into your code, but it’s also very easy to resolve as well. Next time you are viewing your debug output, see if you can spot SQL n + 1 selects.

References

Database access using Spring JdbcTemplate
Preventing the n + 1 select problem when using Hibernate

Having worked for small companies in the past, I can fully understand the problems associated with sending developers to conferences. Sending one developer doesn’t cost a vast amount of money, but if all your developers want to go the money really does start to mount up. After the issue of cost, you then have to factor in the lost development time, not only for the conference but travelling to and from the event as well. The various costs to the business can soon become very prohibitive.

Back in January of this year, I decided that I would make sure I attended a conference this year, and decided I would just pay for it myself. I wanted to see if conferences really are worth the money. After months of discussing it on Spring Forums, I had the pleasure of attending SpringOne in June. The conference, hotel, travel and other costs came in at around £800 (€1200 or US$1600) in total. I also decided to take a weeks holiday from work to make the most of my trip.

The whole trip turned out to be a great experience. I met up with a number of people I had chatted to on various forums, and also lots of other random developers I met in the hotel. We discussed all aspects of software development late into the night, and I also learnt a great deal about a whole range of subjects. We traded lots of horror stories, and I also got to hear about the new exciting projects people were working on. It was great to meet like minded people who were willing to share information and take part in interesting discussions!

Once the conference started, it was a packed three days of presentations and discussions. There were a wide array of presentations running, so there wasn’t a single time I found myself with nothing to do. The conference demanded various levels of ability, so I was able to attend both beginners and advanced presentations as required. I heard a huge amount of information from experts in their field. I was able to chat to numerous developers who’s articles and books I had read, and had the opportunity to find out more about the subject from the original author.

So the big question, was it all worth it? Was it really worth the £800 price tag? As an experience, I’d have to say yes, I really had a great time! I learnt a huge amount both inside and outside of the conference. I learnt about new techniques and technologies, some of which I put directly into use when I returned from the conference. I met a great bunch of people, and I heard some really interesting discussions and insights. I met a number of well known speakers and authors, and got to ask some of the questions that came into my head when I originally read their book(s). The benefits of attending the conference have been numerous, both for me personally but also in my day-to-day work. I came back from the conference with lots of ideas and enthusiasm to try them out. I genuinely learnt a great deal in a short space of time.

So would I do it again? This is a much harder question to answer. I would love to attend another conference, and I may indeed try to attend another next year (QCon, JavaPolis, SpringOne). The two biggest problems are obviously the cost of the event and the use of holidays. If your company is willing to pay for the event and/or let you have time off to go, then it’s obviously worth going. Personally, I’d jump at the chance. As a one off experience, I could justify paying for the conference and taking the holidays, but as a regular event it’s much harder to justify.

Parleys does a great job of sharing lots of presentations, some of which I actually attended. JavaOne and SpringOne also allow you to view and download the presentation slides. Eight hundred pounds might possibly be better spent attending training sessions or achieving certification. The various forums out there, allow you to have regular contact with a huge number of developers from all over the world. Most authors have mailing lists where you can discuss the book with them and with other readers. Lots of the conference experiences can be achieved in some way without actually even attending. However, for me it’s just not the same as being there.

If you still can’t persuade your company to pay for you to attend a conference, there are a few of ways to potentially reducing the cost. Some JUGs have discounted entry to conferences and are also allocated a number of free passes. It might be worth checking your local area to see if there is a JUG near you. Lots of the conferences have an early bird discount as well, so if you book straight away you can save yourself some money. I also collected quite a number of business cards from other attendees, so it’s a great place to get some free publicity for your company. If your boss still isn’t convinced, work really hard and become a Java champion or better yet a conference speaker. That should get you free entry to lots of conferences .

Failing that, if you really want to attend a conference, you might just have to put your hand in your pocket and pay for it yourself. In my humble opinion, it didn’t feel like money down the drain, it was more an investment in myself.

1. Spring Framework reference documentation – I’ve found the reference manual to be the best source of information on the framework. Anytime I have a question, the first place I look is here! It’s constantly updated, and it contains lots of recommendations and best practices from the Spring development team. What better recommendations can you have then the people that wrote it!
2. Spring Framework support forum – If you’re still left with questions after looking through the reference documentation, the Spring support forum provides a very active and friendly community. There are thousands of answers already on there, so it really pays to do a quick search before you post. If you do post a question make sure you do it the smart way.
3. Spring Source Team Blog – Spring from the source. What better place to get information and updates on what the Spring development team are doing.
4. Spring Framework Javadoc – If you want to find details on the API of the Spring classes, the comprehensive JavaDoc is the place to go.
5. Spring Hub – An independent site containing lots of links and resources related to Spring.
6. Spring Framework JIRA – If you think you’ve found a bug or want to propose an enhancement, JIRA is the place to go.
7. Spring Framework Mailing List – If you want to follow the progress of Spring development, you can view the mailing list here or even subscribe.
8. Sample Applications – Spring ships with a number of excellent sample applications. Look through them, play with them and understand them. Many people use these examples as a base for their applications, they are an excellent starting point.
9. Source code – One of the most over looked resources that Spring has to offer is it’s source code. It’s well structured, well written and easy to follow. It’s also a great place to get answers. The source code for the unit tests is also included with the release. What more information could you be looking for?
10. Spring Books – If you are still looking for more information, there are a wide selection of books available. There are several existing threads on Spring forum that discuss the various books and their relative merits.

So what makes JdbcTemplate so much slower than pure Jdbc? In a word…….. nothing. JdbcTemplate does a great job of removing the try/catch/finally/try/catch code we used to write with Jdbc, but under the covers it’s just doing the same old stuff we used to do. It’s getting hold of a connection, executing a statement, possibly mapping a result set to an object, converting any exceptions for us and releasing the connection. That’s pretty much it, it’s a thin wrapper around Jdbc that makes it usable in the real world.

So why do people report performance problems with JdbcTemplate? I took the opportunity to review the comparison that had reported such terrible performance compared to Jdbc. After a couple of minutes reviewing the comparison it was quite obvious it was fatally flawed, not only was it configured differently, it wasn’t testing the same thing. Looking at the comparisons that have been posted in the past on Spring Forum, they typically suffer from the same problems. The most common is they generally don’t perform a fair test. Lets look at the typical problems the comparisons face before seeing the comparison results once the problems were fixed.

1. Connection Pool vs Single Connection

One test uses a connection pool and the other will acquire a new connection every time a statement is executed. This can have differing effects on the test results depending on the initial pool size. If this is set to a high value then typically the connection pool tests will perform slower. Either way, use the same data source for both tests with the same settings.

2. Transactions

One test uses transactions and the other executes non-transactionally, or the transactions are applied at different levels. There’s no point wrapping each query execution in a transaction in one test and in the other test applying it to the service layer. This was actually one of the problems with the original performance comparison. The transactions were applied at the service layer in one test and the DAO in the other.

3. Jdbc RowMapper equivalent doesn’t do anything

This is the most common problem I’ve seen. Although the pure Jdbc version of the code executes a query, the result set is ignored as the results are not processed and mapped into the object representations. This obviously shows a massive improvement over JdbcTemplate as it’s not actually doing anything. If it isn’t processing the results, it’s going to be quicker!

4. Prepared Statements vs String-based queries

Prepared statements are potentially going to be more efficient than string-based queries (depending on platform). Initially the prepared statement is going to be more expensive to create, but if it’s reused it should produce improved performance as it should be available from the statement cache.

5. Batch Statements

One test uses batched prepared statements and the other executes a separate prepared statement.

6. Creating a new ApplicationContext for every test run

Although this is the least common problem, it was actually one of the problems in the aforementioned comparison. If one test uses Spring and the other doesn’t, either create the ApplicationContext outside of the test or at least ensure it’s construction isn’t included in the time taken to complete the test.

Let’s have a look at the performance comparison that was discussed at the beginning of the blog and also the real statistics it produced. The test consisted of creating, updating, deleting and retrieving a number of users. In this example the number of users was set to one thousand, and the test was run one hundred times to give an average time for each operation. For the sake of brevity I’ve only included the code here for retrieving and updating the users, the code for creating and deleting them however followed exactly the same pattern.

This is the pure Jdbc code that retrieves all the users and update the user’s password.

public List<User> getUsers() {
	return jdbcTemplate.query("SELECT * FROM user_details", new RowMapper() {
		public Object mapRow(ResultSet rs, int rowNum) throws SQLException {
			String username = rs.getString("username");
			String password = rs.getString("password");
			return new User(username, password);
		}
	});
}

public void updateUsers(final List<User> users) throws Exception {
	this.jdbcTemplate.batchUpdate("UPDATE user_details SET password = ? WHERE username = ?",
				new BatchPreparedStatementSetter() {
		public void setValues(PreparedStatement ps, int i) throws SQLException {
			User user = users.get(i);
			ps.setString(1, PasswordObfuscator.obfuscate(user.getPassword()));
			ps.setString(2, user.getUsername());
		}

		public int getBatchSize() {
			return users.size();
		}
	});
}

And finally let’s have a look at those all important numbers.

Jdbc DAO
insert: 360ms, fetch: 7ms, update: 276ms, delete: 136ms

JdbcTemplate DAO
insert: 363ms, fetch: 5ms, update: 278ms, delete: 133ms

Transactional Jdbc DAO
insert: 963ms, fetch: 6ms, update: 276ms, delete: 131ms

Transactional JdbcTemplate DAO
insert: 948ms, fetch: 6ms, update: 274ms, delete: 131ms

As expected there’s really not that much in it. Once the issues were fixed in the original comparison they come out pretty much the same. JdbcTemplate doesn’t have the performance problems the original comparison reported and actually shows pretty much the same performance as pure Jdbc. So the moral of the story……. if you are doing a comparison make sure you are comparing the same things and most importantly whatever you tweak, make it a fair test.