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.
Saturday, 28 July 2012
Friday, 27 July 2012
Wednesday, 25 July 2012
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:
Tuesday, 24 July 2012
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.
Saturday, 21 July 2012
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 ?
Wednesday, 18 July 2012
Monday, 16 July 2012
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.
Saturday, 14 July 2012
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.
Friday, 13 July 2012
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.
Tuesday, 10 July 2012
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.
Sunday, 8 July 2012
Thursday, 5 July 2012
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.