Exception Handling with an Entity Manager - jpa

Question

I have heard that when committing transactions using an Entity Manager, it is good practice to try again if the commit fails, since it may be an issue where the object was changed while the transaction was processing.
Does this seem like a proper retry implementation?
int loopCount = 1;
boolean transactionCommited = false;
while(!transactionCommited && loopCount <3) {
EntityManager em = EMF.getInstance().getEntityManager();
try{
EntityTransaction tx = em.getTransaction();
tx.begin();
Player playerToEdit = em.find(Player.class, id);
playerToEdit.setLastName(lastName);
tx.commit();
transactionCommitted = true;
} catch(Exception e){
if(loopCount == 2){
//throw an exception, retry already occurred?
}
} finally{
if(tx.isActive()){
tx.rollback();
}
em.close();
}
loopCount++;
}

Answer 1

As you are caching "Exception" in your catch block, you are retrying to update in situations when the update can't be done. For example, if the Entity can't be found in the database, you are trying to find it twice.
You should catch the most specific exception "OptimisticLockException". This exception is thrown when the version of the Entity doesn't match with the version stored in the database. A Version field in the Entity is a requirement to implement this locking strategy.
There are other locking strategies to be used in high concurrent applications but most of the time a Optimistic Locking strategy is the most appropriate.
As a small detail, using constants for the number of retries instead of "magic numbers" improves code readability and it's easier to modify the number of retries in the future.

Answer 2

Generally it is a bad idea to try again to submit the same changes. Even if the thrown exception is OptimisticLockException, that is not a good idea, as that could mean the someone is overwriting changes that someone has made. Imagine the following scenario:
User 1 changes entityX and commits it.
User 2 changes the a part of fields of the same entityX and tries to commit it. EntityManager throws an exception.
The correct scenario would be here to indicate the exception to the User, so that he re-reads the entity and try again the same modifications.
And now the most important argument why this is dangerous:
At least Hibernate is known that BAD things could happen if you try to reuse the EntityManager after it throwed an exception. Before data gets corrupt or your applicaton stops working as you want, take a look at this article or this one.