Re: [hibernate-dev] @Cacheable
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(a)hibernate.org>
Hibernate.org