Posted by Vincent Partington at around evening time: May 25th, 2009
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:
- The OrderLine with id 30.
- 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.
- 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.
Posted by Vincent Partington at around evening time: May 11th, 2009
In my previous blog on JPA implementation patterns, I touched upon the subject of the DTO and Service Facade patterns. In this blog I will explore why we would even need such patterns and put these patterns and the DAO pattern into the broader context of JPA application architecture.
If there is one thing that I learned when implementing JPA for the first time is that some of the “old school” enterprise application architecture patterns still apply, even though some people have proclaimed them to be no longer necessary:
- The DAO has been declared dead because you might just as well invoke the EntityManager directly. It provides a nice enough interface and switching from JPA to a different persistence implementation is not something the DAO abstraction would make much easier.
- DTO’s have been deemed superfluous because you can also use your domain objects directly in the presentation layer. This is made possible by a combination of the open EntityManager in view pattern, tag libraries to display your domain objects in JSP’s and data-binding utilities to map HTTP request parameters back to domain objects.
- And finally Service Facades also seem to have gone out of fashion. Instead you can have the controller directly invoke the services it needs or, even simpler, directly contain the business logic.
Posted by Vincent Partington at around evening time: April 27th, 2009
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…)
Posted by Vincent Partington in the early morning: April 9th, 2009
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…)
Posted by Vincent Partington around lunchtime: April 3rd, 2009
Last week I talked about how to save an entity. And once we’ve saved an entity we’d also like to retrieve it. Compared to managing bidirectional associations or saving entities, retrieving entities is actually rather simple. So simple I doubted whether there would be much point in writing this blog . However we did use a few nice patterns when writing code for this. And I’m interested to hear what patterns you use to retrieve entities. So here is the next instalment in the series on JPA implementation patterns.
Basically, there are two ways to retrieve an entity with JPA:
- EntityManager.find will find an entity by its id or return null when that entity does not exists.
- If you pass a query string specified in Java Persistence Query Language to EntityManager.createQuery it will return a Query object that can then be executed to return a list of entities or a single entity.
Posted by Vincent Partington at around evening time: March 23rd, 2009
We kicked off our hunt for JPA implementation patterns with the Data Access Object pattern and continued with the discussion of how to manage bidirectional associations. This week we touch upon a subject that may seem trivial at first: how to save an entity.
Saving an entity in JPA is simple, right? We just pass the object we want to persist to EntityManager.persist. It all seems to work quite well until we run into the dreaded “detached entity passed to persist” message. Or a similar message when we use a different JPA provider than the Hibernate EntityManager.
(more…)
Posted by Vincent Partington in the early evening: March 16th, 2009
Last week we started our search for JPA implementation patterns with the Data Access Object pattern. This week we continue with another hairy subject.
JPA offers the @OneToMany, @ManyToOne, @OneToOne, and @ManyToMany annotations to map associations between objects. While EJB 2.x offered container managed relationships to manage these associations, and especially to keep bidirectional associations in sync, JPA leaves more up to the developer.
(more…)
Posted by Vincent Partington mid-afternoon: March 9th, 2009
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…)
Posted by Vincent Partington in the late evening: January 26th, 2009
I’ve just read Robert C. Martin’s Clean Code and Kent Beck’s Implementation Patterns back to back. I actually picked up Clean Code first because my colleagues were raving about it. But then Robert Martin’s book quotes from Kent Beck’s book on the third page of the first chapter already, and disagrees with the quote, so I decided it’d be fun to read Implementation Patterns too. 
(more…)
Posted by Vincent Partington at around evening time: January 19th, 2009
Two years ago I blogged about annotations and that I considered them to be A Bad Thing. It seems I will have to eat my words. I am actually using them to the hilt in my current project.
We use JPA and specific Hibernate annotations on our entities. See for example these annotations on a field:
@OneToMany(mappedBy = "changePlan", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
@org.hibernate.annotations.Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@org.hibernate.annotations.Sort(type = org.hibernate.annotations.SortType.COMPARATOR,
comparator = PositionableComparator.class)
private SortedSet
(more…)