How to avoid blocking EDT with JPA lazy loading in Swing desktop apps

Question

I'm struggling with real-world use of JPA (Hibernate, EclipseLink, etc) in a Swing desktop application.

JPA seems like a great idea, but relies on lazy loading for efficiency. Lazy loading requires the entity manager exist for the lifetime of the entity beans, and offers no control over what thread is used for loading or any way to do the loading in the background while the EDT gets on with other things. Accessing a property that happens to be lazily loaded on the EDT will block your app's UI on database access, without even the opportunity to set a busy cursor. If the app is running on wifi/3G or slow Internet that can make it look like it has crashed.

To avoid lazy loading stalling the EDT I have to work with detached entities. Then, if I actually need the value of a lazy property all my components (even those that should supposedly be able to be unaware of the database) have to be prepared to handle lazy loading exceptions or use PersistenceUtil to test for property state. They have to dispatch entities back to the database worker thread to be merged and have properties loaded before being detached and returned again.

To make that efficient, my components need to know in advance what properties of a bean will be required.

So, you'll see all these shiny tutorials demonstrating how to whip up a simple CRUD app on the NetBeans Platform, Eclipse RCP, Swing App Framework, etc using JPA, but in reality the approaches demonstrated violate basic Swing practices (don't block the EDT) and are completely non-viable in the real world.

( More detail in write-up here: http://soapyfrogs.blogspot.com/2010/07/jpa-and-hibernateeclipselinkopenjpaetc.html )

There are some related questions with somewhat helpful responses, but none of them really cover the edt blocking / lazy loading / entity manager lifetime management issues together.

http://stackoverflow.com/questions/1778578/lazy-eager-loading-strategies-in-remoting-cases-jpa

How are others solving this? Am I barking the wrong tree by trying to use JPA in a desktop app? Or are there obvious solutions I'm missing? How are you avoiding blocking the EDT and keeping your app responsive while using JPA for transparent database access?

Answer 1

I've only used JPA with an embedded database, where latency on the EDT wasn't a problem. In a JDBC context, I've used SwingWorker to handle background processing with GUI notification. I haven't tried it with JPA, but here's a trivial JDBC example.

Addendum: Thanks to @Ash for mentioning this SwingWorkerbug. A workaround is to build from source has been submitted.

Answer 2

I have encountered the same problem. My solution was to disable lazy loading and ensure that all entities are fully initialised before they are returned from the database layer. The implications of this is that you need to carefully design your entities so that they can be loaded in chunks. You have to limit the number of x-to-many associations, otherwise you end up retrieving half the database on every fetch.

I do not know if this is the best solution but it does work. JPA has been designed primarily for a request-response stateless app. It is still very useful in a stateful Swing app - it makes your program portable to multiple databases and saves a lot of boilerplate code. However, you have to be much more careful using it in that environment.