[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

> 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 at hibernate.org>

More information about the hibernate-dev mailing list