Open spring-projects-issues opened 8 years ago
Oliver Drotbohm commented
That indeed feels suspicious, but I am suspecting the version to be null
after the lookup, as pretty much everything else is checked to be non null
before. Is your cache messing with the object instance maybe? Are you sure you're wiping instances from the cache correctly? The optimistic locking exception seems to indicate that intermediate persistence operations are not reflected in the cached instances correctly.
Andrew Walters commented
I'll try and get a setup running where I can debug this to give more information but it's proving a little tricky at the moment
Andrew Walters commented
Yeah, looks like this one is down to a simple a lack of Serializable on the @MappedSuperClass
where the @LastModified
and @Version
fields are declared.
Feel free to close as "Not a defect"
Andrew Walters opened DATAREST-761 and commented
This looks to be similar (or a regression?) to DATAREST-581 though not specific to projections.
My scenario is around a repository findOne(id) method annotated with
@Cacheable
backed by an ehCache RMI based implementation. When invoked on Node A the find method works as intended and the entity is written to the cache. When subsequently invoked on Node B however it results in the below stack:Presumably this is due to being unable to extract the Version property from the serialized entity.
It further results in update operations to the entity failing as the cached version doesn't have the correct version information (409 Conflict):
It may be potentially relevant - the
@Version
'ed property is declared on a@MappedSuperclass
with private access and public getterAffects: 2.4.2 (Gosling SR2)