[hibernate-dev] @Cacheable

[Emmanuel Bernard]

On  Jul 15, 2009, at 22:01, Steve Ebersole wrote:

> On Wed, 2009-07-15 at 16:26 -0400, Emmanuel Bernard wrote:
>> The spec made an incursion into caching metadata and allow to cache
>> some classes and not others. So far so good. But that includes the
>> scenario where these classes are inside the same class hierarchy
>>
>> Case 1
>>
>> @Cacheable(false)
>> class Person {}
>>
>> @Cacheable(true)
>> class customer extends Person {}
>>
>> Case 2
>>
>> @Cacheable(true)
>> class Person {}
>>
>> @Cacheable(false)
>> class customer extends Person {}
>>
>> Can we support that?
> We store hierarchy in a single region based on the root entity.  In
> other words, in this case Person is root entity; that is the cache
> region for both Person and for Customer in this example.  That's what
> allows us to serve from the cache properly when they say "load  
> Person X"
> given that that data might identify either a Person or a Customer.
> Supporting this mixing would destroy that Hibernate feature and take a
> lot of time to do so to boot.

Let me try and parse that properly.

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
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.
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?


>
>> Second problem, they want "easy" caching ootb but do not define
>> caching strategies. What would be a good caching strategy default  
>> if a
>> class is marked as cached but no caching strategy is defined?
> Well the answer as to the best default AccessStrategy to use is
> unfortunately going to depend.  It depends on the RegionFactory  
> defined
> and various other configuration choices.
>
> Let's assume that user still needs to define the RegionFactory.  I can
> see delegating this choice to the defined RegionFactory.  It would  
> still
> depend on other variables like are we using some form of JTA-based
> transactions and have access to the TransactionManager, etc.  But its
> much better than Hibernate code needing to intrinsically understand  
> the
> capabilities of all RegionFactory impls (what about a custom
> RegionFactory???).  Maybe this looks something like a new  
> RegionFactory
> method: AccessType getDefaultAccessType(???) (AccessType is the enum  
> for
> TRANSACTIONAL, READ_ONLY, etc).  Not sure what all we would need to  
> pass
> in to the method; probably the TransactionFactory and the
> TransactionmanagerLookup; others?

I am concerned about the idea of having this value changing depending  
on your environment (JTA or not).

Do you think this will provide values to customers or is it a  
marketing / shineware feature.


>
>
> -- 
> Steve Ebersole <steve at hibernate.org>
> Hibernate.org
>