EC.preCommit L1Cache op IS NULL!

Steve Springett

I have an application that, upon initial startup, creates about a 100,000 objects in a h2 database (using JDO). Each object is committed in its own transaction.

About half way through, the log spits out "EC.preCommit L1Cache op IS NULL!".  The only place I find a reference to this error message is in the source file:

The message doesn't occur all the time, but it does occur most of the time - usually around the same spot. In terms of persisting, I'm using the following code:


I'm really at a loss here. Any help would be greatly appreciated.


"EC.preCommit" will only ever be in that 1 class (EC = ExecutionContext(Impl)). And the L1 cache will only ever be updated in that 1 class.
Consequently if there is a NULL value in the L1 cache you'd need to debug all places where variable "cache" has "put" called on it with a null value (putObjectIntoLevel1Cache?), and debug why.
If it never puts a null in, but you get one out then you look at whether you are using a PM multi-threaded(!!!) and fix your code to NOT do that. Or look at the class of the "cache" object.

FWIW, DataNucleus provides a mechanism for providing an initialisation SQL file to load up objects, which would run a damn site more efficiently than just instantiating objects and going through JDO (see property datanucleus.generateSchema.scripts.load and its related properties)

Steve Springett

I think I figured it out. The problem only surfaced when running on Java 9.0.1 inside a Docker container when heap was exhausted (but no OutOfMemory errors displayed).

Moving back to Java 8_151 (inside Docker) but with -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap and a large enough heap specified, and the message went away. It was a seriously strange problem without any indication it was memory related. I have not tried increasing the heap on Java 9 so I don't know if 9 has issues or was just masking the fact it was a memory issue. 8 told me right away by throwing OutOfMemoryError.

Thanks for the heads up on the script loading. For most of my use-cases, I will not know the data in advance of initial start-up, but I plan on using the script loading to populate default/demo data. That'll be really convenient.