Be extra aggressive on getTuple cache within a flush

Description

In OgmEntityPersister.update, we do an explicit getTuple call without going to the OgmEntityExtraState cache in some "sensitive" situations like optimistic locking check for backends that don't support atomic compare and update. Same for insert to check the presence or not of the object in the datastore.
I imagine other areas don't use the cache as well (see OGM-1153).

In the "sensitive" situations, we need to be a bit less aggressive and consider valid a cache entry that has been loaded during the same flush.
One option is to add to a cache entry, the (to be defined) flush uuid / unique identifier or even an object reference. If the cache entry has been loaded by the same flush, use the cached entry, otherwise for a getTuple call.

See GridDialectOperationInvocationForOneToOneTest and the extra getTuple that could be avoided.

Environment

None

Activity

Show:
Emmanuel Bernard
August 31, 2016, 2:13 PM

Same for getAssociation caching once in place.

Assignee

Unassigned

Reporter

Emmanuel Bernard

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Priority

Major
Configure