Thanks for attempting to fix this problem and providing a PR. It would IMO be better though to avoid the mutation in the first place i.e. BaseSqmToSqlAstConverter should IMO not mutate the SQM tree.

@beikov: Thanks, I tried to address your comment in 9803134. I might have missed the point though. Please let me know if I've taken a wrong turn.

Here’s my reasoning behind the change:

Lazily initializing the reusablePaths map is inherently a data race. I guess this was done to avoid the costs of the HashMap if it’s not needed? My suggestion is to pre-initialize it to avoid the data race but use a zero initial size for the ConcurrentHashMap to avoid the memory overhead. This might cause many resizes though and might be a bad idea.

As far as I understood, we need some kind of locking / synchronization mechanism at least somewhere in the code path between QuerySqmImpl.executeUpdate and AbstractSqmPath.resolvePath. I might missed the point where you think that locking/synchronization should happen?

Thanks, but you're missing the point. BaseSqmToSqlAstConverter should not cause mutations in the first place. We will have to figure out which call sites in BaseSqmToSqlAstConverter currently do cause mutations and replace them, such that it is thread safe by e.g. allocating the SqmBasicValuedSimplePath or EntityDiscriminatorSqmPath directly.

As far as I can see, problematic call sites in BaseSqmToSqlAstConverter are:

• sqmStatement.getRoot().get( versionMapping.getPartName() ) in addVersionedAssignment
• sqmStatement.getTarget().get( versionAttributeName ) in visitInsertionTargetPaths
• 2x temporalPath.get( ZONE_OFFSET_NAME ) in transformDurationArithmetic
• lhs.type() in createTreatTypeRestriction

@beikov Ok, I kind of expected that I missed the point. Unfortunately I guess I’m way too unfamiliar with the Hibernate codebase to make a useful contribution in this case.
Should I rather close this MR or should I rework to only add the unit test?