[hibernate-dev] HHH-10162 Inheritance and L2 cache

Christian Beikov christian.beikov at gmail.com
Fri Mar 3 19:38:06 EST 2017


Thanks for the comments, I have updated the PR.

I think that it is important to have a complete fix and I am already 
working on that, but this issue was specifically about the L2 cache, so 
I wanted to keep that stuff separate.

Here are some other polymorphism related issues:

  * https://hibernate.atlassian.net/browse/HHH-9845
  * https://hibernate.atlassian.net/browse/HHH-11280
  * https://hibernate.atlassian.net/browse/HHH-4742
  * https://hibernate.atlassian.net/browse/HHH-2927

The fix provided by Josh Landin for HHH-11280 would break reference 
equality and I think that is something we all want to keep. Which brings 
us to the actual problems.

1. Whenever we encounter an association that is of a polymorphic entity 
type, we should actually internally, regardless of what the user 
configures, always fetch that association with subtypes. Otherwise we 
could run into that same problem again, that we "pollute" the L1 cache 
with a proxy of the wrong type. Since we want to keep reference 
equality, we can't replace that instance.

2. When using bytecode enhancement, the loading of *ToOne instances 
could be deferred to the first access.

3. Actually it would also be possible if property access is used without 
bytecode enhancement, but that would require to use a special proxy for 
every object that might contain a non-initialized polymorphic 
association. The speciality about it is that it loads the association on 
first access.

4. Another thing that we should consider is "merging" of fetched state 
into existing instances of the L1 cache. Imagine a user loads an entity 
X and some of it's associations are lazy loaded. Then the user sets of a 
query that would fetch that association. Currently the associations will 
be left untouched because we skip any further processing as soon as we 
encounter the instance for X in the L1 cache. What we should actually do 
is, merge any fetched state into the instance if possible.

Since 1. will probably affect performance, it might only make sense to 
do it along with 2. or 3.

Regardless of these improvements, I think we should apply the L2 cache 
fix and handle the rest later.

What do you say?


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 04.03.2017 um 00:42 schrieb Gail Badner:
> Hi Christian,
>
> I've added some comments to the PR.
>
> As I mentioned there, this appears to be a partial fix. If the 
> application really requires the entity to implement the "correct" 
> class, then this will still break for them when the entity is not in 
> the cache.
>
> I'm not sure if a partial fix really suffices. IIUC, enhancement would 
> work.
>
> What to others think about this?
>
> Regards,
> Gail
>
> On Thu, Mar 2, 2017 at 11:59 AM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     I can, just wanted to hear some general opinions before creating
>     the PR.
>     Will do that tomorrow.
>
>
>     Mit freundlichen Grüßen,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     Am 02.03.2017 um 20:57 schrieb Gail Badner:
>     > Hi Christian,
>     >
>     > You mentioned that you reproduced the issue, but I don't see a test
>     > case. Can you push your test case to a PR?
>     >
>     > Thanks,
>     > Gail
>     >
>     > On Thu, Mar 2, 2017 at 10:15 AM, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>
>     > <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>     >
>     >     BTW, regarding the Hip Chat "Dev" room, I'd personally not
>     rely on
>     >     replies
>     >     from there.  E.g. I never saw your question there, and others
>     >     likely did
>     >     not either.  FWIW we had all agreed on a block of time when we
>     >     would try to
>     >     be available in that room specifically to discuss such things.
>     >     IIRC that
>     >     was roughly between 10 and 12 my time (central US).
>     >
>     >     On Thu, Mar 2, 2017 at 12:08 PM Christian Beikov
>     >     <christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>>
>     >     wrote:
>     >
>     >     > Hey guys,
>     >     >
>     >     > Steve said I should start a discussion about the possible
>     >     solution for
>     >     > HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162>
>     >     <https://hibernate.atlassian.net/browse/HHH-10162
>     <https://hibernate.atlassian.net/browse/HHH-10162>>> so here we
>     >     > go.
>     >     >
>     >     > While debugging the issue, I found out that the proxy is
>     created at
>     >     > DefaultLoadEventListener.createProxyIfNecessary() where it IMO
>     >     should
>     >     > consult the 2L cache first by calling existing =
>     >     > loadFromSecondLevelCache( event, persister, keyToLoad );. The
>     >     fix looks
>     >     > easy, but I am not sure of the implications. Obviously
>     this will
>     >     affect
>     >     > performance a little since it has to consult the L2 cache now.
>     >     >
>     >     > I tried to start a discussion in the Dev room, but so far only
>     >     Andrea,
>     >     > Vlad and Chris have commented this. Has anyone a different
>     idea for
>     >     > implementing this?
>     >     > --
>     >     >
>     >     > Mit freundlichen Grüßen,
>     >     >
>     >   
>      ------------------------------------------------------------------------
>     >     > *Christian Beikov*
>     >     > _______________________________________________
>     >     > hibernate-dev mailing list
>     >     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>>
>     >     _______________________________________________
>     >     hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>>
>     >
>     >
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>



More information about the hibernate-dev mailing list