In the careers of most Spring/Hibernate developers I know, there sooner or later comes a point of no escape...they have to write a Hibernate user type. The first one is usually of the copy'n'paste variety, and by and large works perfectly well.
But when things are no longer going quite as expected - Hibernate is ignoring changes to items managed by the user type, for instance - it often becomes apparent that one doesn't sufficiently understand how these user type thingies are supposed to work. At least, that's what happened to me.
In this post, we'll be dissecting the Hibernate UserType interface, explaining the relationships between the various methods, and developing a set of base user types that capture common use cases. (more...)

Tags: Hibernate user type
Filed under Hibernate, JPA, Java | 7 Comments »

Last week I discussed the relative merits of field access versus property access in the ongoing JPA implementation patterns blog series. This week I will dwell on the choices offered when mapping inheritance hierarchies in JPA.

JPA provides three ways to map Java inheritance hierarchies to database tables:

1. InheritanceType.SINGLE_TABLE - The whole inheritance hierarchy is mapped to one table. An object is stored in exactly one row in that table and the discriminator value stored in the discriminator column specifies the type of the object. Any fields not used in a superclass or a different branch of the hierarchy are set to NULL. This is the default inheritance mapping strategy used by JPA.
2. InheritanceType.TABLE_PER_CLASS - Every concrete entity class in the hierarchy is mapped to a separate table. An object is stored in exactly one row in the specific table for its type. That specific table contains column for all the fields of the concrete class, including any inherited fields. This means that siblings in an inheritance hierarchy will each have their own copy of the fields they inherit from their superclass. A UNION of the separate tables is performed when querying on the superclass.
3. InheritanceType.JOINED - Every class in the hierarchy is represented as a separate table, causing no field duplication to occur. An object is stored spread out over multiple tables; one row in each of the tables that make up its class inheritance hierarchy. The is-a relation between a subclass and its superclass is represented as a foreign key relation from the "subtable" to the "supertable" and the mapped tables are JOINed to load all the fields of an entity.

A nice comparison of the JPA inheritance mapping options with pictures, and including a description of the @MappedSuperclass option, can be found in the DataNucleus documentation.

Now the interesting question is: which method works best in what circumstances?
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 5 Comments »

Last week my colleague Albert Sikkema blogged about using UUIDs as primary keys. Interesting stuff, thanks again, Albert! This week I will continue the JPA implementation patterns series by discussing the relative merits of field access vs. property access.

The JPA specification allows two ways for the persistence provider to access the persistent state of an entity. The persistence provider can either invoke JavaBeans style property accessors (getters and setters) or access the instance fields of the entity directly. Which method is used depends on whether you have annotated the properties or the fields of an entity.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java, Performance | 1 Comment »

Continuing Vincent Partington's blog series about JPA implementation patterns, I would like to add the following

The default way in JPA for primary keys is to use the @GeneratedValue annotation with the strategy attribute set to one of AUTO, IDENTITY, SEQUENCE, or TABLE. You pick the most appropriate strategy for your situation and that's it.
But you can also choose to generate the primary key yourself.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 12 Comments »

Two weeks ago I blogged about the use of the Service Facade and Data Transfer Object pattern in JPA application architecture. This week I will move from the high level perspective and discuss an interesting interaction I discovered between the way bidirectional associations are managed and lazy loading. So let's roll up our sleeves and get dirty in this next installation of the JPA implementation patterns series.

This blog assumes that you are familiar with the Order/OrderLine example I introduced in the first two blogs of this series. If you are not, please review the example.

Consider the following code:

OrderLine orderLineToRemove = orderLineDao.findById(30);
orderLineToRemove.setOrder(null);

The intention of this code is to unassociate the OrderLine with the Order it was previously associated with. You might imagine doing this prior to removing the OrderLine object (although you can also use the @PreRemove annotation to have this done automatically) or when you want to attach the OrderLine to a different Order entity.

If you run this code you will find that the following entities will be loaded:

1. The OrderLine with id 30.
2. The Order associated with the OrderLine. This happens because the OrderLine.setOrder method invokes the Order.internalRemoveOrderLine method to remove the OrderLine from its parent Order object.
3. All the other OrderLines that are associated with that Order! The Order.orderLines set is loaded when the OrderLine object with id 30 is removed from it.

(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 7 Comments »

In the previous three blogs about JPA implementation patterns, I covered the basis operations of saving entities, retrieving entities, and removing entities. In this blog I will continue along a different angle, exploring the subject of how entities are lazily loaded and how that affects your application.

Anybody that has been working with Hibernate for a while has probably seen a LazyInitializationException or two, usually followed by a message such as "failed to lazily initialize a collection of role: com.xebia.jpaip.order.Order.orderLines, no session or session was closed" or "could not initialize proxy - no Session". Even though these message may baffle new users of Hibernate, they are a lot better than the NullPointerExceptions OpenJPA gives you in these cases (at least when using runtime bytecode enhancement).

To use JPA to its full potential it is imperative to understand how lazy loading works, as it allows you to model your complete database with all its relations without loading that whole database as soon as you access just one entity.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java, Spring | 15 Comments »

For the last few weeks I have been covering the implementation patterns I discovered while writing JPA applications. The last two blogs covered saving entities and retrieving entities. But when you're really through with your entities, I guess you'd want to remove them too. So that is the subject of this blog.

Just like retrieving an entity, removing an entity is pretty simple. In fact it's all you need to do is pass the entity to the EntityManager.remove method to remove the entity from the database when the transaction is committed (Of course you'd actually invoke a remove method on your DAO which in turn invokes EntityManager.remote). That's all there is to it. Usually. Because when you're using associations (be they bidirectional or not) things get more interesting.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 14 Comments »

San Francisco 31 March - 3 April: Web 2.0 Expo brought together people with diverse professional backgrounds, having interest in Web 2.0, at Mascone Centre in San Francisco. San Francisco Bay Area, also known as Silicon Valley boasts of high concentration of information technology companies of all sizes ranging from biggies like Intel Corporation to numerous start ups trying to make it big.
(more...)

Filed under Agile, Hibernate, JavaOne, Scrum, Web 2.0 | 2 Comments »

Hibernate is a sophisticated ORM framework, that will manage the state of your persistent data for you. Handing over the important but difficult task of managing persistent state of your application to a framework has numerous advantages, but one of the disadvantages is that you sort of lose control over what happens where and when. One example of this is the dirty checking feature that Hibernate provides. By doing dirty checking, Hibernate determines what data needs to be updated in your database. In many cases, this feature is quite useful and will work without any issues, but sometimes you might find that Hibernate decides to update something that you did not expect. Finding out why his happened can be a rather difficult task.
(more...)

Tags: dirty checking, Hibernate, StaleObjectStateException, versioning
Filed under Hibernate | 7 Comments »

The JPA, short for Java Persistence API, is part of the Java EE 5 specification and has been implemented by Hibernate, TopLink, EclipseLink, OpenJPA, and a number of other object-relational mapping (ORM) frameworks. Because JPA was originally designed as part of the EJB 3.0 specification, you can use it within an EJB 3.0 application. But it works equally well outside of EJB 3.0, for example in a Spring application. And when even Gavin King, the designer of Hibernate, recommends using JPA in the second edition of Hibernate in Action, a.k.a. Java Persistence with Hibernate, it's obvious that JPA is here to stay.

Once you get over your fear of annotations , you find that there is plenty of literature out there that explains the objects and methods within the API, the way these objects work together and how you can expect them to be implemented. And when you stick to hello-world-style programs, it all seems pretty straight forward. But when you start writing your first real application, you find that things are not so simple. The abstraction provided by JPA is pretty leaky and has ramifications for larger parts of your application than just your Data Access Objects (DAO's) and your domain objects. You need to make decisions on how to handle transactions, lazy loading, detached object (think web frameworks), inheritance, and more. And it turns out that the books and the articles don't really help you here.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java, Spring | 45 Comments »