Home » Eclipse Projects » EclipseLink » JPA DAO in Desktop Application
|
| Re: JPA DAO in Desktop Application [message #480327 is a reply to message #480317] |
Sat, 15 August 2009 05:59   |
 Tom Eugelink
Messages: 825
Registered: July 2009 |
Senior Member |
|
|
> 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
|
|
|
| Re: JPA DAO in Desktop Application [message #481136 is a reply to message #480327] |
Wed, 19 August 2009 17:35 |
Marc Schlegel
Messages: 92
Registered: July 2009 |
Member |
|
|
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
|
|
|
| Re: JPA DAO in Desktop Application [message #481212 is a reply to message #481136] |
Thu, 20 August 2009 07:34 |
Thomas Haskes
Messages: 147
Registered: July 2009 |
Senior Member |
|
|
Marc Schlegel schrieb:
> 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.
I think Tom is right, it really depends on what you want to do. I also
think that the approach to reuse one singleton instance of the em is not
wrong at all, for example if you have one global save action in your app
(like we have in our project) it is useful to just have one instance of
the em. If this leads to an exception in your case, there may be a
configuration issue.
I would like to give a note about the spring dm thougths. If you use
spring dm to manage the emf and the em, you only have to options (and to
me only one works nice), as the spring-configuration only lets you
decide between singleton and prototype scope of spring beans (there are
more scopes, but there are all only working in the web tier because they
are session related). The latter creates a new instance of a bean every
time which is not really working unless you dont't have long running
transactions. So what I mean to say is, if decide to use spring, the
singleton approach is the easiest way to set things up (I'm not
confident enough to say "the only" unless I feel that way :-))
By the way, we develop a single sourced application that runs both on
desktop an in the web and use the singleton approach (session-singleton
for the web case) and it works like a charm.
As a hint, the use of spring does not necessarily make your life easier,
as the configuration can be tricky, too.
In the end its all about concepts and your specific requirements.
I hope you have fun playing around with those options,
Another Tom
|
|
| |
Goto Forum:
Current Time: Mon Jan 13 04:42:01 GMT 2025
Powered by FUDForum. Page generated in 0.04166 seconds |
] 
Search
Help
Register
Login
Home
