In this post we will do a deep dive into Spring transaction management. We will go over on how does @Transactional really works under the hood. Other upcoming posts will include:

• how to use features like propagation and isolation
• what are the main pitfalls and how to avoid them

You may recall from my post Autocomplete search box with jQuery and Spring MVC, that I use jQuery ui autocomplete to dynamically search for keywords on Podcastpedia.org. I am now in the process of migrating the source base for Podcastpedia.org to Spring 4. I decided to go with the latest version 4.1.0.RELEASE and everything worked pretty smoothly until I got to test the auto-complete functionality presented in the post mentioned before.

In one of my projects I had a requirement to load reference data from several sources in a Java EE 6 WebLogic environment, with EclipseLink as ORM framework. Since I couldn’t find an annotation in the Java EE world comparable to the sweet @Cacheable from Spring YET, I had to write my “own” caching solution. Although reference data barely changes over time, one extra requirement was to be able to clear the cache from exterior. So here it goes…

Introduction

In my previous post I introduced the entity state transitions Object-relational mapping paradigm.

All managed entity state transitions are translated to associated database statements when the current Persistence Context gets flushed. Hibernate’s flush behavior is not always as obvious as one might think.

Introduction

Hibernate shifts the developer mindset from SQL statements to entity state transitions. Once an entity is actively managed by Hibernate, all changes are going to be automatically propagated to the database.

Manipulating domain model entities (along with their associations) is much easier than writing and maintaining SQL statements. Without an ORM tool, adding a new column requires modifying all associated INSERT/UPDATE statements.