• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Patterns for EJB3/JPA Disconnected Result Sets

 
Alex Peake
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can anyone point me to some patterns for disconnected result sets coming from an EJB3/JPA middle tier?

The EJB business object gets results from an Entity, and disconnects. The results are serialized from the middle tier to the client (Java Swing in this case). The user adds to, edits and deletes from the result set. I now need to get these changes back to the database.

Is it best to keep "before" and "after" copies and let the business object review and compose the changes? Or maybe track a "change set" on the client? Or some other well accepted method that I am unaware of?

Any hints would be appreciated.

Thanks

Alex
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well in the JPS there is the EntityManager which can re-attached disconnected objects (look at merge) and with versioning it reconnect the object, then start to manage its state. You can also tell it to do a select first to see if any changes have occured before calling the commit. You do not have to do anything on your part to check the "dirtiness" of the detached object.

Mark
 
Alex Peake
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Mark for your help.

Forgive me if I misunderstand, but I believe merge is first of all to do a SQL UPDATE, and second, to work on a single row.

What I have is a Collection of rows, some of which will be deleted (as well as adds and updates). I am looking for the pattern to handle the Collection, and in particular the delete action.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well merge is for the EntityManager to check the database and the version to see if you had worked on the latest, or if someone made changes underneath. While it takes an object, depending on your cascade setting it can go down to the Collections that it holds. That is why I mentioned it.

So merge is for it to get the latest form the database and merge your detached changes so that everything is now being Dirty Checked for you to do your update. Deleting objects in Collections is based on your cascade settings for the Association.

Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic