I'm getting the below error (rather "randomly') when loading certain fields of my entities. I don't know where to start looking. Any kind of advice is appreciated.

On DN 5.2 with SQL Server. Let me know if you need more info, thanks.

org.datanucleus.exceptions.NucleusObjectNotFoundException
No such database row
org.datanucleus.store.rdbms.request.FetchRequest#execute(FetchRequest.java:439)
org.datanucleus.store.rdbms.RDBMSPersistenceHandler#fetchObject(RDBMSPersistenceHandler.java:316)
org.datanucleus.state.StateManagerImpl#loadFieldsFromDatastore(StateManagerImpl.java:1542)
org.datanucleus.state.StateManagerImpl#loadUnloadedFieldsInFetchPlan(StateManagerImpl.java:3897)
org.datanucleus.state.StateManagerImpl#isLoaded(StateManagerImpl.java:4112)
domainapp.modules.dcp.dom.quest.dissag.slots.CustomDisaggregationVariableSlot#dnGetdisabled(CustomDisaggregationVariableSlot.java:-1)
domainapp.modules.dcp.dom.quest.dissag.slots.CustomDisaggregationVariableSlot#isDisabled(CustomDisaggregationVariableSlot.java:49)

On Wed, Jul 7, 2021 at 08:24 AM, <mwhesse@...> wrote:

loadUnloadedFieldsInFetchPlan

Wondering about that bit, is this an indicator that the field was loaded previously and has been unloaded? Under which circumstances would that happen? And why does reloading the field fail?

This is an indicator that a field is NOT loaded and something wants it. Only you know your class, and what field you have there, and what is invoked to try to get that field

Thanks Andy. Does this mean we should try to load these fields eagerly?

It also seems this only happens under higher load. 

What would be a good place to start looking for why this exception is being thrown? Thankful for any clue, really.

An exception is thrown because it cant find the object in the DB to get the fields from. And it has SQL in the log so you know what it is invoking at that point. So work backwards why it cant find it.

Thanks, Andy. It turned out this (and other strange "effects") was seemingly caused by the L2 cache. When we disabled it it went away.

The l2 cache performs a very simple task (providing access to field values across PMs) and is not the cause of "strange effects". If a field is required and is available in the L2 cache then it populates it from there. If you have some object in some other PM that had the field then it is made available to other PMs. Just enabling/disabling features isn't the way to debug your problems. Disabling the L2 cache will have an impact on speed. Your choice.

Yes, well aware, and I will dig deeper into it, since we would like to re-enable L2 caching. 

Another issue we observed when using the L2 cache in our Apache Isis app was that sometimes (?) when an object could not be found in L1 and L2 and was added to L1 the postLoad event was not triggered. Since in Apache Isis dependencies are injected into entities through this event we had cases in which the dependencies were null. In such cases the state of the object was "hollow" (as opposed to "persistent clean"). Also haven't had time to dig deeper into this.