Opened 18 years ago
Closed 18 years ago
#251 closed defect (fixed)
Row was updated or deleted by another transaction in trashcan
| Reported by: | Nicklas Nordborg | Owned by: | Nicklas Nordborg |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | web | Version: | |
| Keywords: | Cc: |
Description
Items mapped by cascade="delete" may result in exception when deleting them from the trashcan
The scenario is this: We have items A and B of two different types. B is a child item to A and the mapping is such that if A is deleted then B is deleted by cascade. Ie. The relation is mapped with cascade="delete" in the mapping file.
Now, we have flagged both A and B for deletion and use the trashcan to delete them. The actual order of deletion is not known, so it might be that B is deleted before A. Then when A is about to be deleted Hibernate follows the cascade and tries to delete B again. Since, B has already been deleted this results in an exception like the following:
Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [net.sf.basedb.core.data.MessageData#4]
In this case the Message was connected to a Job which cascade deletes all messages linked to the job. Ie. the job is the A item and the message is the B item.
I think this could be a bug in Hibernate which should *know* the best deletion order. Since every action is put into the Hibernate cache and isn't executed until a commit() is called it is uncertain if a changed deletion order on our side will change this behaviour.
(In [2284]) Fixes #251: Row was updated or deleted by another transaction in trashcan
Deleted a call to HibernateUtil.flush() in DbControl.commit(). This was introduced just a few weeks ago to solve some other problem with the trashcan... But I think this problem has been solved by the iterative approach now implemented in the trashcan.