We're updating the issue view to help you get more done. 

Validity Audit Strategy is painfully slow due to many flushes

Description

When ValidityAuditStrategy.perform() handles a MOD or DEL (and, in HHH-8280, an ADD too), it needs to find the last audit entry for this entity and update its revision end. This lookup is done via query, so naturally, the persistence context must be flushed, so that the query picks up any changes that aren't yet in the database. This happens in autoFlushIfRequired().

Anyway, this state of affairs can lead to an obscene number of flushes when the number of changes in this committed transaction is high. Database latency and Hibernate dirty checking can make flushes expensive, so it's in our interest to minimize them where possible.

In this case, I don't see why a flush on every perform() is necessary. A single flush separating the session's real work from the audited work should be sufficient, because neither the new audit entries nor the new revision will factor into the query issued by perform(). That query is only interested in looking up audit entries belonging to past revisions.

Without such an optimization, the validity audit strategy issues tons of flushes. In my application, I commit one transaction with low thousands of changes to entities. With the default strategy, I see 46 flushes. With validity, I see 6160.

Environment

None

Status

Assignee

Unassigned

Reporter

Adar Dembo

Labels

None

Worked in

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Community Help Wanted

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Affects versions

4.2.2

Priority

Major