The N +1 Select Problem in Hibernate

Consider our simple Book and Shelf relation. Every shelf has a collection of Books. As we have not applied any optimization strategies, when we request for a Shelf object from the database, a Shelf proxy is loaded. Then when we access a scalar property (like code) the Shelf scalar properties get loaded using a select query. The Book set is represented by a proxy. Now if we try to access the collection a second fetch is needed.

Using Interception in Hibernate -2

To continue from where we left our previous discussion, byte code interception is mainly used when we need to lazily load some of our properties.

Using Interception in Hibernate -1

As we saw in our earlier post, Hibernate allows us to lazily load columns in a table row using interception. Interception is used instead of proxies. Consider our Book- Shelf relation. If we wish to replace the Shelf proxy and instead using interception then the hbm files would have the following change:

lazy="extra"

Hibernate uses proxies to ensure that the data is fetched only on a need basis. So if we have a Shelf class that has a set of books, the loading of a shelf object will not load the Book set. Instead a collection proxy will be assigned to the field. It is only when we access the methods of the collection, that the actual fetch occurs.

Are Interceptors Thread Safe ?

Our audit interceptor had several instance members that it used for audit management. For example there was the Set that kept track of all the new entities. What would happen of two threads simultaneously operate on the set. Or in a more general sense, is our interceptor thread safe ? Is it necessary for it to be thread safe ?

Logging using Interceptors

One of the most popular uses of Interceptors is to log object creations/insertions and deletions. Interceptors allow you to transparently log these state changes and manage the audit trail for an entity.

Testing the Interceptor

In the previous post we created a simple Interceptor that logged different operations to the console when they occurred. For testing I created an Entity class that has a one-to-one relation and a collection and decided to test out various operations on it.

Spring and Events and Listeners

Spring's ApplicationContext provides the functionality to support events and listeners in code. Spring allows us to create listeners in the code. We can create beans that listen for events which are published through our ApplicationContext. This is achieved via the ApplicationEventPublisher interface.

Hibernate Queries and the Question Mark

The one thing we see in logs when we use Hibernate is the Question Mark. The question mark makes its appearance in all queries generated whether you use HQL or Criteria or do a load on the object identifier. If we need to debug a query, we need to actually copy the values from bind parameters and then replace them for the question marks. This (and I am sure developers will agree with me ) is a pain. Real PAIN.

Listeners in Hibernate

Hibernate 3.x is built on the concept of events and listeners.To deal with the different operations like loading an object, saving an object, Hibernate creates events. There exists listeners in the Hibernate framework listening for these events.

The MessageSourceAware Interface

While we can use the ApplicationContext for Internationalization, we may also need the functionality to be available to normal beans.

Reloadable MessageSources

As we saw in the previous post, the ResourceBundleMessageSource uses underlying JDK's ResourceBundle implementation. The java.util.ResourceBundle loads locale specific files or bundles only once. It caches loaded bundles forever: Reloading a bundle during program execution is not possible. As this MessageSource relies on ResourceBundle, it faces the same limitation.So we are stuck with the same set of values. Spring provides us with an alternative implementation - ReloadableResourceBundleMessageSource.

Spring and Message Loading

One of the advantages of using the application context is that we can load locale specific messages using the ApplicationContext. More simply put Spring includes Localization and Internationalization support.

Lazily loading beans ?

One of the differences between BeanFactory and ApplicationContext is their method of loading beans. The beanfactory lazily loads beans. It creates the bean only when the getBean() method is called.