8:27 a.m.
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
9:08 a.m.
New subject: @Cacheable
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 <steve(a)hibernate.org>
Hibernate.org
5609
days inactive
5609
days old
1 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Steve Ebersole