[JIRA] (HHH-13916) Pending-put should not be created by Infinispan when checking if an entity is transient
by Gail Badner (JIRA)
Gail Badner ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiNzdlYWExYzE0... ) / Improvement ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiNzdlYW... ) HHH-13916 ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiNzdlYW... ) Pending-put should not be created by Infinispan when checking if an entity is transient ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiNzdlYW... )
Change By: Gail Badner ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
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 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 {{ SessionImpl }} 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.
( https://hibernate.atlassian.net/browse/HHH-13916#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13916#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100123- sha1:a8fd8fd )
4 years, 8 months
[JIRA] (HHH-13916) Pending-put should not be created by Infinispan when checking if an entity is transient
by Gail Badner (JIRA)
Gail Badner ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiZGVhODhhNzcy... ) / Improvement ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiZGVhOD... ) HHH-13916 ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiZGVhOD... ) Pending-put should not be created by Infinispan when checking if an entity is transient ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiZGVhOD... )
Change By: Gail Badner ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
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.
( https://hibernate.atlassian.net/browse/HHH-13916#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13916#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100123- sha1:a8fd8fd )
4 years, 8 months
[JIRA] (HHH-13916) Pending-put should not be created by Infinispan when checking if an entity is transient
by Gail Badner (JIRA)
Gail Badner ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYzQ3YzBmZWIy... ) / Improvement ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiYzQ3Yz... ) HHH-13916 ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiYzQ3Yz... ) Pending-put should not be created by Infinispan when checking if an entity is transient ( https://hibernate.atlassian.net/browse/HHH-13916?atlOrigin=eyJpIjoiYzQ3Yz... )
Issue Type: Improvement Affects Versions: 5.3.16, 5.4.13 Assignee: Unassigned Created: 30/Mar/2020 21:14 PM Fix Versions: 5.4.14 Priority: Major Reporter: Gail Badner ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... )
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-commo... ). 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.
( https://hibernate.atlassian.net/browse/HHH-13916#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13916#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100123- sha1:a8fd8fd )
4 years, 8 months
[JIRA] (HHH-13915) Shared interceptor in BasicProxyFactoryImpl leads to intermittently broken persistence
by Henry Clout (JIRA)
Henry Clout ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5bd6e4b... ) *commented* on HHH-13915 ( https://hibernate.atlassian.net/browse/HHH-13915?atlOrigin=eyJpIjoiZTlkMT... )
Re: Shared interceptor in BasicProxyFactoryImpl leads to intermittently broken persistence ( https://hibernate.atlassian.net/browse/HHH-13915?atlOrigin=eyJpIjoiZTlkMT... )
I’ve created a PR with a fix, but an as yet to be completed test. Inlined from the PR:
This PR is for discussion purposes only. The fix addresses the issue described in my application, but I've not yet been able to get a test configuration to mimic the break.
The issue is that the test code does not lead to the use of a BasicProxyFactoryImpl for the composite unique constraint, whereas in my application this is the case.
Digging through debug stack traces, I suspect this is because in my application Hibernate is representing the constraint in the entityMetamodel as an:
EntityBasedCompositionAttribute : Attribute(name=unique-props, type=component[guid,customer] [non-identifier,composition])
Whereas in my test code it is a:
EntityBasedAssociationAttribute : Attribute(name=discriminator, type=org.hibernate.test.uniqueproperties.UniquePropertiesTest$Discriminator [non-identifier,association])`
Any thoughts on how to change the test configuration to have it exercise a BasicProxyFactoryImpl would be greatly appreciated.
(Note: the commented out test was an initial PoC on test setup - I will clean this up having resolved the above)
I’ll keep plugging away at the test, but any pointers would be received with gratitude!
( https://hibernate.atlassian.net/browse/HHH-13915#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-13915#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100122- sha1:8399ad5 )
4 years, 8 months