As a last resort, {{ AbstractEntityPersister#isTransient }} calls {{ CacheHelper.fromSharedCache }} to determine if an entity is cached. If the return value is non-null, then the {{ AbstractEntityPersister#isTransient }} returns {{ false }} , and the return value is ignored.
When Infinispan is the cache provider, {{ CacheHelper.fromSharedCache }} calls [ {{ InvalidationCacheAccessDelegate#get }} |https://github.com/infinispan/infinispan/blob/9.4.x/hibernate/cache-commons/src/main/java/org/infinispan/hibernate/cache/commons/access/InvalidationCacheAccessDelegate.java#L56-L65]. If the entity that is not already cached, {{ InvalidationCacheAccessDelegate#get }} adds a pending-put for the entity as a side-effect. The entry in the pending-put map uses a {{ SessionImpl }} as the map key.
If that entity really is transient, then the pending-put entry never gets cleared until it times out. Since the pending-put map contains {{ SessionImpl }} keys, those objects cannot be garbage-collected until the entry times out.
If lots of data is in the process of being imported, then an {{ OutOfMemoryError }} could be thrown. IIUC, it is not recommended to use the cache when importing data. That is why I am calling this issue an "improvement" rather than a "bug". {{ [WFLY-13259|https://issues.redhat.com/browse/WFLY-13259] }} contains a test that reproduces this issue.
This improvement involves changing {{ AbstractEntityPersister#isTransient }} to call {{ CachedDomainDataAccess#get }} , which calls {{ InvalidationCacheAccessDelegate#get }} with a {{ null }} {{ session }} argument. Since {{ session }} is {{ null }} , {{ InvalidationCacheAccessDelegate#get }} does not add a pending-put for the entity. |
|
