Allow disabling of invalidation of second-level cache entries for multi-table entities
Description
Activity
Chris Cranford February 13, 2018 at 5:53 PM
I think its safe enough here to simply say that compliance means we omit the table-span check at all.
Thanks for the clarification above, @Steve Ebersole. I also agree and second Andrea's feelings that until we get a test that shows otherwise we take this approach.
Andrea Boriero February 13, 2018 at 9:53 AM
I think its safe enough here to simply say that compliance means we omit the table-span check at all.
I agree, at least till someone can provide a test that shows this causes issues.
Steve Ebersole February 12, 2018 at 6:57 PM
I wonder if we are over-thinking this. An update against this entity will always hit the root table first. That acts as a block between T1 and T2. E.g., consider a schema with persons (Person root) and crm_pers (Person secondary table) tables.
P1 updates persons and acquires a write lock. P2 will be blocked as soon as it tries to update persons as well. So I'm not sure the optionality of these secondary tables has any role here.
I think its safe enough here to simply say that compliance means we omit the table-span check at all.
@Andrea Boriero - optional indicates that that no-row in the secondary table is interpreted as all null values. We may handle it that way on save, cannot remember exactly
Andrea Boriero February 12, 2018 at 6:21 PM
@Steve Ebersole marking the join table as non optional means that an Entity cannot have all the attributes mapped to the the secondary table null, am I right?
Steve Ebersole February 12, 2018 at 2:49 PM
I'm a little torn on exactly how this setting should work. Specifically should this force all secondary tables to be non-optional, even if the user explicitly configured them to be optional? Or should it only affect secondary tables where the user did not explicitly say?
Either answer covers the JPA TCK case btw. Because explicitly specifying optional/non requires Hibernate-specific metadata, the TCK is obviously not going to have explicitly defined these.
@Andrea Boriero @Chris Cranford @Former user?
Historically Hibernate would invalid the cache entries for an entity defined with multiple secondary tables (unless that entity were versioned) rather than write data for update and/or insert. This setting would allow disabling that. The reason being that the JPA 2.2 TCK started testing the provider's caching configuration by actually persisting data via EntityManager and then asking the
javax.persistence.Cacheimplementation (Hibernate) whether that entity is cached or not.Changes
Should limit the checks based on secondary tables to just optional ones. If all tables are non-optional then this is less of a worry.
Add setting to allow marking all join tables as non-optional (
hibernate.jpa.compliance.caching).