Thoughts on using JPA-Entities in dialogs


You have detached JPA Entities and you want to edit them in a GUI Dialog with the use of Databinding (JFace, SWT). How to avoid dirty entity state and minimize server roundtrips?

Basic User Story

In the GUI you have a list of detached entities from your remote server. The user picks one of the entities. The Dialog opens, the user can edit the selected entity instance and clicks „Save“.

Problems and obstacles

  • the user may click „Cancel“, thus the Entity may remain dirty
  • another user may have changed the record

Approach 1 – reload on cancel

After the user presses „Save“ in the dialog, the edited entity instance gets back to
the back-end service and merge is performed: em.merge(entity). The Databinding will have copied all user interace changes to the entity. Very simple and straight
forward approach.
Drawback: if the user clicks „Cancel“ the entity will remain dirty in your front-end process space and you will need to reload this entity from the backend and probably put it back
to the font-end’s list. But this might be very complex. You will more properly reload the entire list again.

PROs: Save is simple.

CONs: „Cancel“ case is only acceptable if you have either A) a very short and simple list of entities to load or B) that you can simply reload just one entity and merge it into the
front-end list.

Dialog Action Server Roundtrips
Save 2 (1x Save, 1x Reload List)
Cancel 1 (Reload List)

Approach 2 – copy() method

In this Approach the entity implements an Interface that declares a copy method / or has a copy construct. Ones the user picks an Entity, you create a copy of the Entity, and that copy is then used in the dialog. In the „Save“ case, Databinding has updated the second instance, that you will give to the backend, and there you will call EntityManager.merge(secondInstance). In the „Cancle“ case you simply discard the copy instance. There is no Need to refresh the list.

PROs: No roundtrip in the „Cancel“ case. This might be the most performant solutions in regard to network load and server roundtrips.

CONs: All or at least the entities in the front-end list have to implement the special Interface and thus implement a copy() method / or copy constructor. This copy() method needs to be maintained. That may be a bit too much work to do, especially if you have a lot of chaninging entities.

Dialog Action Server Roundtrips
Save 2 (1x Save, 1x Reload List)
Cancel 0

Approach 3 – realod before edit

When the user picks the entity in the list to edit it, before giving the entity to the dialog you reload a fresh copy from your remote service. This second instance of the entity is then used in the dialog. The second instance is detached as well. In the „Save“ case, Databinding will have updated the instance. When the second instance gets back to the remote service, EntityManager.merge(secondInstance) will be called. Thats it. In the „Cancel“ case you simply discard the second instance and the gabage collector will take care of it.

PROs: You always edit the most recent state of the entity, thus minimizing the possibility of lost updates. Cancel-case is quite simple.

CONs: Even in the cancel case one server roundtrip is required. That might be to expensive on weak networks – but sill less expensive then Approach 1’s „Cancel“ case.

Dialog Action Server Roundtrips
Save 3 (1x Reload Entity, 1x Save, 1x Reload List)
Cancel 1 (Reload Entity)


Approach 3 is the best.