[hibernate-dev] @Cacheable
Steve Ebersole
steve at hibernate.org
Thu Jul 16 10:08:04 EDT 2009
> 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 alleviate anything
either.
> 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
it.
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 at hibernate.org>
Hibernate.org
More information about the hibernate-dev
mailing list