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. 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 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.