|RE: AW: [eclipselink-dev] SVN main commit: bug#304738 - option to avoid possible database deadlock in updates|
This is a very rare deadlock that can occur on some databases. Difference databases have different conflict resolution, and different deadlock avoidance and detection. In most cases it might make sense to allow the database to handle this rare possibility, than requiring the sort overhead on all updates from JPA. There is a persistence unit option for it, so it is very easy to enable for the entire application. Application servers are free to choose their own defaults, so could enable this if they choose in the persistence unit properties they pass EclipseLink.
EclipseLink actually ends up partial ordering updates without this setting, as the object changes sets are hash ordered by primary key. Because of this, it is quite difficult to reproduce this deadlock even when trying very hard.
why make this configurable?
Not sorting updates can lead to nasty and hardly reproducible/investigatable deadlock situations. At least, ordered updates should be the default, I think.
If we enable sorting would it be better to sort on the fly as the
changesets are added to the UnitOfWorkChangeSet instead of resorting the list
SVN main commit: bug#304738 - option to avoid possible database deadlock in updates
It is currently possible for uow updates for a class to occur in a
non-consistent order. This can cause a possible deadlock on the database if
multiple threads are updating the same set of objects at the same time.
This fix adds an option to uow to allow updates within a class to be ordered by pk.
Code review: Andrei (pending)
- Added database update deadlock test to client-server test suite
- Added persistence unit property, "eclipselink.order-updates" to allow updates to be ordered
- Made ObjectChangeSet and CacheId Comparable to allow ordering by id
- Added check in CommitManager to sort change sets before updating
- Fixed aggregate check for batch reading in ForeignReferenceMapping include aggregate-collection
eclipselink-dev mailing list