You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to enable field-based Optimistic Locking (using a Version-annotated field), but could not get it to work with DataNucleus. It ends up with an NPE along with the following message: Exception thrown while loading remaining rows of query
See the stack trace below and the datanucleus.log file.
Looking into the persistence unit properties, I located the culprit: disabling the Level2 Cache (via the 'datanucleus.cache.level2.type' property) does cause the error. It works when I set it to any other type: soft or weak.
For reference, I tested the same case against other JPA Providers (EclipseLink and Hibernate) via different Maven Profiles and the test does pass as expected.
Is not being able to use Optimistic Locking without an L2 Cache an intended behavior? Or am I missing something?
15:27:33,298 (main) ERROR [DataNucleus.General] - >> Exception in operation execution
java.lang.NullPointerException
at org.datanucleus.store.rdbms.fieldmanager.ResultSetGetter.fetchLongField(ResultSetGetter.java:115)
at org.datanucleus.state.StateManagerImpl.replacingLongField(StateManagerImpl.java:1924)
at mydomain.model.AbstractBaseJpaEntity.dnReplaceField(AbstractBaseJpaEntity.java)
at mydomain.model.AbstractIdentifiable.dnReplaceField(AbstractIdentifiable.java)
at mydomain.model.Person.dnReplaceField(Person.java)
at mydomain.model.AbstractBaseJpaEntity.dnReplaceFields(AbstractBaseJpaEntity.java)
at org.datanucleus.state.StateManagerImpl.replaceFields(StateManagerImpl.java:4290)
at org.datanucleus.state.StateManagerImpl.replaceFields(StateManagerImpl.java:4315)
at org.datanucleus.store.rdbms.request.FetchRequest.execute(FetchRequest.java:419)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.fetchObject(RDBMSPersistenceHandler.java:316)
at org.datanucleus.state.StateManagerImpl.loadFieldsFromDatastore(StateManagerImpl.java:1512)
at org.datanucleus.state.StateManagerImpl.loadUnloadedFieldsInFetchPlan(StateManagerImpl.java:3867)
at org.datanucleus.store.rdbms.mapping.java.PersistableMapping.getObject(PersistableMapping.java:780)
at org.datanucleus.store.rdbms.fieldmanager.ResultSetGetter.fetchObjectField(ResultSetGetter.java:176)
at org.datanucleus.state.StateManagerImpl.replacingObjectField(StateManagerImpl.java:1965)
at mydomain.model.Address.dnReplaceField(Address.java)
at mydomain.model.AbstractBaseJpaEntity.dnReplaceFields(AbstractBaseJpaEntity.java)
at org.datanucleus.state.StateManagerImpl.replaceNonLoadedFields(StateManagerImpl.java:4343)
at org.datanucleus.store.rdbms.query.PersistentClassROF$1.fetchNonLoadedFields(PersistentClassROF.java:507)
at org.datanucleus.ExecutionContextImpl.findObject(ExecutionContextImpl.java:3214)
at org.datanucleus.store.rdbms.query.PersistentClassROF.findObjectWithIdAndLoadFields(PersistentClassROF.java:476)
at org.datanucleus.store.rdbms.query.PersistentClassROF.getObject(PersistentClassROF.java:382)
at org.datanucleus.store.rdbms.fieldmanager.ResultSetGetter.processSubObjectFields(ResultSetGetter.java:222)
The text was updated successfully, but these errors were encountered:
Hi there!
I tried to enable field-based Optimistic Locking (using a Version-annotated field), but could not get it to work with DataNucleus. It ends up with an NPE along with the following message: Exception thrown while loading remaining rows of query
See the stack trace below and the datanucleus.log file.
Looking into the persistence unit properties, I located the culprit: disabling the Level2 Cache (via the 'datanucleus.cache.level2.type' property) does cause the error. It works when I set it to any other type: soft or weak.
For reference, I tested the same case against other JPA Providers (EclipseLink and Hibernate) via different Maven Profiles and the test does pass as expected.
Is not being able to use Optimistic Locking without an L2 Cache an intended behavior? Or am I missing something?
A test case is available in this Git repo: https://github.com/rm3l/dn-issue-optimistic-locking-jpa
Stacktrace:
The text was updated successfully, but these errors were encountered: