Allow disabling of invalidation of second-level cache entries for multi-table entities

Description

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.Cache implementation (Hibernate) whether that entity is cached or not.

Changes

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

  2. Add setting to allow marking all join tables as non-optional (hibernate.jpa.compliance.caching).

Environment

None

Activity

Show:
Steve Ebersole
February 12, 2018, 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
February 12, 2018, 6:21 PM

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

- 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 13, 2018, 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.

Chris Cranford
February 13, 2018, 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, . I also agree and second Andrea's feelings that until we get a test that shows otherwise we take this approach.

Assignee

Steve Ebersole

Reporter

Steve Ebersole

Fix versions

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major
Configure