Version number incremented even if all changes of the entity were reverted by an interceptor

Description

In our application we have a Hibernate interceptor which may revert all changes made to an entity in the onFlushDirty() method, based on various conditions. After doing so, our onFlushDirty() implementation returns true indicating that the currentState array has changed.

It works as expected in most cases but we experience the following if all property values are reverted:

  • the entity is not updated in the database - as expected

  • the version number of the entity is still incremented - this means that the database and the entity will not be in sync after flush

I investigated the problem and found the following code in DefaultFlushEntityEventListener.isVersionIncrementRequired():

Code:
private boolean isVersionIncrementRequired(
FlushEntityEvent event,
EntityEntry entry,
EntityPersister persister,
int[] dirtyProperties
) {
final boolean isVersionIncrementRequired = entry.getStatus()!=Status.DELETED && (
dirtyProperties==null ||
Versioning.isVersionIncrementRequired(
dirtyProperties,
event.hasDirtyCollection(),
persister.getPropertyVersionability()
)
);
return isVersionIncrementRequired;
}

In our case dirtyProperties is null (because all dirty properties were reverted by the interceptor), so isVersionIncrementRequired() will return true. It means that the version is incremented even if no properties were changed and no database update is performed when flushing.

Thanks for your help in advance!
Norbi

Environment

win xp, java 6

Activity

Show:
Gail Badner
February 14, 2011, 9:40 PM

Norbert, thanks for checking. It sounds like it was not caused by HHH-5908. The fix is probably in related code.

ZoltanZ
February 15, 2011, 9:41 AM

Can we expect this issue to be fixed soon, or should we find a workaround?

Gail Badner
February 18, 2011, 3:20 AM

I'm not sure when this will be fixed.

If you have a workaround, then please provide it here so others can see it.

Any ideas about a fix?

Brett Meyer
April 7, 2014, 5:41 PM

In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.

If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.

Thank you!

Brett Meyer
July 8, 2014, 3:10 PM

Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!

Assignee

Unassigned

Reporter

ZoltanZ

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure