Re: [eclipselink-users] Stale Data Between GUIs Using EclipseLink JPA

[Chiovari Cristian Sergiu <csergiu77@xxxxxxxxx>]

Tim nice description but can you provide a sample applications where all
this good practice advices are demonstrated.

It would be very very helpful !

THx


--- On Tue, 1/13/09, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:

> From: Tim Hollosy <hollosyt@xxxxxxxxx>
> Subject: Re: [eclipselink-users] Stale Data Between GUIs Using EclipseLink JPA
> To: "EclipseLink User Discussions" <eclipselink-users@xxxxxxxxxxx>
> Date: Tuesday, January 13, 2009, 12:57 AM
> I'd like to chime in here, speaking from experience
> going from a real
> production JDBC/RCP app to EclipseLink.
> 
> You need to be smart about how you create your
> EntityManager.
> 
> Here's how we did it, I'll use RCP terms, but
> it'd probably be
> translatable to Swing.
> 
> The main plugin had it's own EMF.
> 
> Each View had it's own EntityManager, it kept this EM
> for it's life.
> These views once created, weren't created and destroyed
> often.
> 
> Each Editor had it's own EntityManager, it tracked
> changes using the
> UnitOfWork API, (a great thing we got for free).
> 
> Also, by using EclipseLink we could reuse our Entities
> directly in the
> UI and easily hook everything from text boxes to drop down
> boxes, to
> table controls directly using DataBinding API's
> designed to work with
> JavaBeans.
> 
> After the conversion, I would never ever ever go back to
> straight
> JDBC. The code is so much cleaner and so much easier to
> write.
> 
> ./tch
> 
> 
> 
> On Mon, Jan 12, 2009 at 4:10 PM, James Mello
> <james.mello@xxxxxxxxx> wrote:
> > Usually ORM solutions can be faster. Quite a bit of
> your poor performance may be related to you getting and
> releasing an EntityManager per database operation. This is a
> classic "anti" pattern that is discussed in a
> hibernate FAQ.
> >
> > Also, realize that one reason an SQL solution may be
> faster too is that you currently have a contrived flat
> object representation. When moving to more complex objects,
> the required SQL becomes more difficult to write and things
> like Lazy fetch and fetch groups really start to shine in
> both development cost and performance. Finally, I would add
> that you really only need to perform good enough. If the
> eclipselink solution is taking say 100ms to do something
> versus 10ms, if it isn't performance critical, err on
> the side of ease of development Using a JPA solution you can
> do post development profiling and thunk to native SQL where
> necessary reducing bother code complexity and the amount of
> classes you need.
> >
> > -----Original Message-----
> > From: eclipselink-users-bounces@xxxxxxxxxxx
> [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of
> Liford, Michael W.
> > Sent: Monday, January 12, 2009 11:59 AM
> > To: EclipseLink User Discussions
> > Subject: RE: [eclipselink-users] Stale Data Between
> GUIs Using EclipseLink JPA
> >
> > Thanks for the reply, James.
> >
> > I read a message in a newsgroup that recommended
> getting a new EntityManager for every database operation and
> closing it right after the operation. I also surrounded any
> updates, inserts, and deletes with transactions and commits.
> Seems to work now.
> >
> > I am rather disappointed in the performance of
> EclipseLink. I have another version of the same application
> using native SQL (ResultSet, PreparedStatement, etc.). It is
> much faster. EclipseLink makes the coding easier, but there
> is a price to pay.
> >
> > MikeyL
> >
> > -----Original Message-----
> > From: eclipselink-users-bounces@xxxxxxxxxxx
> > [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On
> Behalf Of James Sutherland
> > Sent: Monday, January 12, 2009 10:58 AM
> > To: eclipselink-users@xxxxxxxxxxx
> > Subject: Re: [eclipselink-users] Stale Data Between
> GUIs Using EclipseLink JPA
> >
> >
> > In JPA an EntityManager represents an extended
> persistence context, in that any object read into the
> EntityManager will remain until you either
> > close() or clear() the EntityManager.  You can also
> call refresh() on an object to refresh it explicitly.  An
> EntityManager normally relates to a single transaction or
> request.  So to see changes made in another EntityManager,
> or another machine, you need to either create a new
> EntityManager, or clear() the existing one, or refresh()
> each object you want refreshed.
> >
> > EclipseLink also managed a 2nd level shared cache at
> the EntityManagerFactory level.  This cache also caches the
> objects that are read, so if you want fresh data you must
> also ensure this cache is refreshed.  Calling refresh() will
> also refresh the cache (unless you have flushed changes),
> the cache also has invalidation API and configuration, or
> can be disabled using persistence.xml
> "eclipselink.cache.shared.default"="false",
> or the @Cache annotation or orm.xml.
> >
> > I would recommend you continue working with JPA, and
> not use the native API or Mapping Workbench.
> >
> >
> > MikeyL wrote:
> >>
> >> I am playing with a Movie-Actor application to
> learn about
> >> persistence. I have a Derby database with a Movies
> table with title,
> >> rating, release year, etc., and an Actors table
> with name, birth date,
> >
> >> etc. I have an associative table joining a
> many-to-many relationship
> >> between Movies and Actors. The associative table
> declares foreign key
> >> fields with references back to the parent tables.
> I designed Swing
> >> GUIs to display the data. The Movie GUI will
> display actors for a
> >> selected movie in a child table. The Actor GUI
> will display movies for
> >
> >> a selected actor in a child table. The Entity
> Manager Factory and
> >> Entity Manager are instantiated once by the main
> GUI at program start.
> >
> >> The Movie and Actor DAOs get the Entity Manager
> from the main screen.
> >> The problem is that changes made in one GUIs do
> not get reflected in
> >> the other. E.g., if I add the movie 2 Days in the
> Valley to actress
> >> Charlize Theron in the Actor GUI then click on 2
> Days in the Valley in
> >
> >> the Movie GUI, Charlize is not listed as an actor
> in the child table.
> >> Even pressing the Refresh button to reload the
> Movie table does not
> > help. How do I synchronize the data between the two
> GUIs?
> >>
> >> In an attempt to solve the above problem, I took a
> look at EclipseLink
> >
> >> Sessions. It seems that I could have the main GUI
> invoke a server
> >> session and have separate client sessions for the
> Movie and Actor
> >> GUIs. However, when using Workbench to create
> entity source files from
> >
> >> my database tables the many-to-many relationship
> is not picked up by
> >> Workbench although the foreign key reference
> constraints are on the
> >> associative table. I crawled all over the
> User's Guide and can't find
> >> how to manually define these relationships in the
> mapping XML file. Is
> > this a bug in Workbench?
> >>
> >> Any help and thoughts will be appreciated.
> >>
> >> MikeyL
> >>
> >
> >
> > -----
> > ---
> >
> http://wiki.eclipse.org/User:James.sutherland.oracle.com
> James Sutherland http://www.eclipse.org/eclipselink/
> >  EclipseLink , 
> http://www.oracle.com/technology/products/ias/toplink/
> > TopLink
> > Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink
> , http://wiki.oracle.com/page/TopLink TopLink
> > Forums: 
> http://forums.oracle.com/forums/forum.jspa?forumID=48
> TopLink , http://www.nabble.com/EclipseLink-f26430.html
> EclipseLink
> > Book:  http://en.wikibooks.org/wiki/Java_Persistence
> Java Persistence
> > --
> > View this message in context:
> >
> http://www.nabble.com/Stale-Data-Between-GUIs-Using-EclipseLink-JPA-tp21
> > 353727p21417041.html
> > Sent from the EclipseLink - Users mailing list archive
> at Nabble.com.
> >
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> >
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> >
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> >
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> >
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users