[hibernate-dev] HHH-12146 - subclass-specific caching

Steve Ebersole steve at hibernate.org
Tue Dec 12 09:49:21 EST 2017


HHH-12146 is about being able to enable/disable caching at various levels
in an entity hierarchy.  E.g., given a hierarchy such as `Person` and
`Company` both extending `LegalEntity`, this would allow users to say that
only `Company` should be cached but not `Person` nor any other
`LegalEntity` subclass.

The underlying approach here is to still define region and access-strategy
information per-hierarchy - users will simply be able to opt out of (or
into) caching particular subclasses.  In my initial attempt I simply
allowed both `@Cache` and `@Cacheable` to appear anywhere in the
hierarchy.  However, allowing `@Cache` (as currently defined) implies that
users should be able to define different regions and/or access strategies
for various subclasses within the hierarchy.  Stepping back, I thought a
better solution would be to continue to support `@Cache` only at the root
level and define this new feature in terms of `@Cacheable` at the various
levels.  This has a few implications that I wanted to discuss.

The main thing is that this means that applications using just `@Cache` to
define caching would still only be able to declare caching for the entire
hierarchy.  But I think that is ok because that was the legacy behavior,
and so nothing is really changing there.  If we find `@Cache` on the root
we'd assume an implicit `@Cacheable(true)`.  I think some examples will
help explain...


Current behavior

@Inheritance(...)
@Cache(...)
abstract class LegalEntity {
    ...
}

class Person extends LegalEntity {
    ...
}

class Company extends LegalEntity {
    ...
}

In the current behavior both  `@Cache` and `@Cacheable` are only valid on
the root as seen above.  Placing them on any subclass results in an error.
Note too that we could have used `@Cacheable` here instead of `@Cache` in
which case the default `@Cache` values would be applied.  It was also legal
to use both together.  In fact, a portable application would use
`@Cacheable` with or without `@Cache`.


Proposed behavior

@Inheritance(...)
@Cache(...)
@Cacheable(false)
abstract class LegalEntity {
    ...
}

class Person extends LegalEntity {
    ...
}

@Cacheable(true)
class Company extends LegalEntity {
    ...
}

Here we have the root disabling caching (assuming
`SharedCacheMode.ENABLE_SELECTIVE`).  `Person` inherits that setting.
 `Company` however overrides that to enable caching.  We still have
`@Cache` attached to the root to define the specifics of caching (region,
access strategy).  But as noted earlier, we could have left off `@Cache`
and accepted the defaults.

I also propose that we continue to accept `@Cache` (without explicit
`@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode`
plays a part in that too.

Anyway, I wanted to make sure everyone agrees with this.


More information about the hibernate-dev mailing list