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?
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.
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.
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
subject: Patterns for EJB3/JPA Disconnected Result Sets
0
