> 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 <st...@hibernate.org> Hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org http://lists.jboss.org/mailman/listinfo/hibernate-dev
