Provides an interface for Level 1 caches.
Interface for any Level 2 Cache used internally.
Abstract starting point for a third-party L2 cache plugin.
An object that is stored in the Level2 Cache keyed by the identity of the persistable object.
Simple implementation of a plugin for use of javax.cache (v0.61+) product with DataNucleus.
Implementation of a query results cache using javax.cache (v0.3+) interface.
FieldManager responsible for populating the provided CachedPC object.
FieldManager responsible for retrieving the values from the provided CachedPC object.
Representation of a class whose objects will be pinned when put into the L2 cache.
Null implementation of a Level 2 Cache.
Soft implementation of a Level 2 cache.
Level 1 Cache using Soft referenced objects in a Map.
Implementation of a Level 1 cache keeping strong references to the objects.
Weak referenced implementation of a Level 2 cache.
Level 1 Cache using Weak referenced objects in a Map.
The first is within the PersistenceManager and is the Level 1 Cache. There are 3 available implementations of a Level 1 Cache here :- SoftRefCache, WeakRefCache and HardRefCache. They provide varying degrees of object retention during the garbage collection process.
The second is across multiple PersistenceManagers within the same PersistenceManagerFactory, and is the Level 2 Cache. There is one implementation of a Level 2 Cache here :- DefaultLevel2Cache. Alternatively, there are plugins for EHCache, SwarmCache, OSCache and Coherence products
As far as Level 2 caching is concerned each class is configurable via metadata @Cacheable (and equivalent XML). In addition we can define which fields are cacheable using this mechanism, but maybe using @Extension metadata if the persistence API doesn't support field-level restrictions.
At commit of a transaction we check all enlisted objects and have a recursive process that navigates down through all objects to cache (limited by the FetchPlan) and at the end all of these objects will be put in the L2 cache (and logged). Also at this point if any enlisted objects have been deleted during the transaction we remove them from the L2 cache. When an object is to be put in the L2 cache we check if it already has an entry in the L2 cache and, if so, we update that object with the current field values, version, etc. When an object is to be put in the L2 cache and it has relation fields, we don't store the actual objects of those relations instead storing the identities of the related objects in the CachedPC object. When an object is to be taken from the L2 cache we create a copy of that object and copy the field values across for all fields that were loaded when it was originally put in the cache. When a relation field is required to be loaded we use the identities that are stored in the CachedPC, and find the equivalent object for that identity from the L1/L2 caches, reinstating it into the managed object.
Copyright © 2017. All rights reserved.