[news.eclipse.rt.eclipselink] Re: JPA DAO in Desktop Application

[tbee <tbee@xxxxxxxx>]

> Could somebody clarify this a bit for me, and maybe give a best-practise 
> tip?

I can only tell you how I use Eclipselink in my swing application.

How you use EL depends on how you want your application to behave; in a web application this is quite simple: you need an EM to process the request and after that you're done. For a swing application you have to decide if you want one EM for the whole application or if you want, for example like me, one EM per window.

The latter is a logical setup; all the changes a user makes are limited to that window,  another window the changes are only available as soon as he commits them. The problem is when you introduce a business model; this encapsulated set of classes need to know which EM to use at any given time. It does not know which window it currently is working for, since you have only one BM loaded.

But a stand alone application introduces another problem: when does a transaction start and when does it finish? You cannot start a transaction while the user is editing, because that would cause all kinds of update statements and thus locks and conflict other windows. Like with the submit in a webapplication, you need some kind of save button. When that save button is pressed, a transaction is started, changes are made and written to the database, and a commit or rollback is done. The problem with this is that you need to remember all the changes that were made prior to pressing the save button and applying them when save is pressed. Even worse; if you need to do a rollback some of the entities may already have been persisted and are rolled back by the database, but the in-memory version has its version counter increased. The next persist will throw a already-modifiedd exception.

A lot of joy is going on trying to create a workable environment. I already addressed this with the developers; the spec is very webapp focused.

Anyhow, I have written two extensions on top of JPA / Eclipselink to solve these (and some more) problems.

1. EntityManagerFinder - this is a class used by the business model to find the correct EM. Naturally there is a "singleton" implementation, but also a "Swing" implementation. The Swing implementation examines the component -and from that the window- that currently has the focus. It has a map which binds EM's to windows and thus it can find the correct EM te use. This works automatically 99% of the time. As soon as you start to invoke separate threads for long running tasks, a line of code is required to bind that thread to the correct EM. It's not covering all possible scenario's, but it real life it goes a long way.

2. An extension directly on EntityManager and Transaction which remember all merge, persist and removes when a transaction is not running. When the transaction is started, all these changes are automatically re-applied. Because it does not remember the order in which they happened (I had no need for that), you need to put the database in the suspend-constraint-checking-until-commit mode. Oracle has you create deferred constraints, Informix allows setting this on the connection for all constraints, each database has a different approach.

That is how I have my fat client running. Works fine for over a year now.

Tom