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