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

["Tim Hollosy" <hollosyt@xxxxxxxxx>]

Sure - http://www.weheartcode.com/2008/08/27/eclipselink-in-j2se-rcp-applications/

./tch



On Tue, Jan 13, 2009 at 2:58 AM, Chiovari Cristian Sergiu
<csergiu77@xxxxxxxxx> wrote:
> 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
>
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>