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 Robert van Loghem mid-morning: April 3rd, 2009
On the 15th of April the NLJUG (Dutch Java User group) will be holding their J-Spring conference. Four Xebians will be presenting. Every week we’ll be providing a sneak preview on the podcast of one of those presentations.
The second sneak peek is about The Java Persistence API – How do i build a real application by Vincent Partington.
The preview is in Dutch, a full interview in english will be coming in about 4 weeks.
You can find more information here or read Vincent’s JPA blog series.
Vincent’s presentation is from 14.25 to 15.15
So head on over to the show page or subscribe to our podcast!
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 Arjan Blokzijl mid-morning: February 7th, 2009
I was writing my n-th Dao implementation, this time using JPA.
I (and probably a whole lot of others) usually create a DAO per entity, parameterizing the entity type.
Specific DAO instances for entities implement the generic DAO using their entity type as type parameter. One generic DAO implementation exists, containing common operations like findById, persist, remove, etc. This generic DAO uses the class type specified by the implementing DAO classes (e.g. a Person) to manipulate or query the entity specified by this type. The (slightly) annoying problem for me has always been to instantiate that entity type in the generic DAO superclass. I’ve always done this by just creating a constructor in the generic DAO which takes a class argument containing the required Class of the entity. However, there’s a better way, which I’ll show in this post.
(more…)
Posted by Maarten Winkels in the late evening: December 8th, 2008
In my article on InfoQ I’ve looked into how Grails and Flex can be combined to create a rapid application development platform. I think this is one of the most promising combinations for RIA development at the moment. The Flex space is very happening and there are many initiatives going on. A few days ago I encountered this one on the web: http://www.spicefactory.org/. Apart from the funny name, I think it is a very interesting initiative, because it brings some new concepts to the Flex remoting mix.