Let's assume two scenarii:
1. we still enforce one region per class hierarchy
in this case, would it hurt to have a given class / subclass not
cached whereas others are?
we are still looking for a single region
In your examples the cache lookup for
all entities in the Person
hierarchy resolve to Person#ID. So would it "hurt"? No, I guess not.
It's more just a thing that we need to be very careful about. Say we
have your case-1 (person not cacheable, customer is cacheable); it would
be natural to simply skip the cache lookup during
Session.load( Person.class, id ) because Person is defined as not being
cacheable; but of course we cant skip it, because that Person#id might
in fact be a Customer. So really all that the @Cacheable(false) on
Person is doing is stopping us from putting data into that region when
we *know* it is that specific type/subtype. Is that useful? Dunno.
Can't say it sounds useful.
2. we don't enforce one region per class hierarchy
in this case, we need to precompute the list of regions for a given
class hierarchy and ask each region to answer the question the way
Hibernate does today.
Don't like this at all. Don't think it really helps
I can see that as slow(er)
Also you have more regions to start and that's the slowness you are
referring to at boot time, right?
by "time" I just meant effort.
I am concerned about the idea of having this value changing depending
on your environment (JTA or not).
If we are forced to support this, it has to go
this route. Not all of
our integrations support all of our defined access types; and there is
not currently a single access type that is supported by all. READ_ONLY
is probably closest, but that's not going to be very useful in this
usage. Next up is READ_WRITE, but again not all integrations support
But perhaps I misunderstand your concerns. To me its natural that this
default access-type change based on environment.
Do you think this will provide values to customers or is it a
marketing / shineware feature.
I think you know my feelings on caching in general
Steve Ebersole <steve(a)hibernate.org>