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

[Marc Schlegel <my.mailing.lists@xxxxxx>]

Thank you for this very detailed answer.

In my current setup I am trying to setup a MVP pattern and the only difference
to your window-approach would be that instead of the windows holding a reference
to the EM, the presenter will have and he is also responsible for the business
model.

Your advices regarding multiple EMs at the same time are very usefull, I have to
think more about this before I start coding something. Currently I am trying to
integrate Spring DM in my RCP, at least in the data-bundle/plugin. Lets see what
Spring can do when it comes to the lifecycle of a EM instance, I just know there
is some support for that.

regards
-- Marc

tbee schrieb:
>> 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