retry after rollback
572079May 30 2007 — edited Sep 4 2007Ok, this time I'm sure this isn't a goof up. How do a retry a JPA persist when a previous attempt has failed? Current approach:
- find object
- make alteration that will conflict with a contraint (e.g. unique)
- make a second alteration to confirm the object is written to the DB
- begin transation
- merge
- commit, this will fail with a DatabaseException, this is expected
- rollback is not required
- undo the conflicting change
- begin transation
- merge
- commit, this will fail with a OptimisticLockException "cannot be updated because it has changed or been deleted since it was last read. "
- rollback is not required
Other tried approaches are:
1. findByPk within each transaction, but this will cause any changes to be overwritten from the db in the second attempt, so there is no second update at all.
2. use persist instead of merge, but this will cause an actual insert in the second attempt: Could not insert new row - duplicate value in a UNIQUE INDEX column.
3. refresh before merge, this overwrites all changes, so there is no update.
For some reason, after the initial persist failed, Toplink seems to have been reset. I can understand how this would work for a request based setup, but this is not the preferred situation in a fat-client setup.