[hibernate-dev] Mutable natural key caching?

[Steve Ebersole]

Using query cache for this was not TheRightWay imho.  HHH-2879 is about
rectifying that and doing it what I (and others) think is TheRightWay.
In other words, implementing HHH-2879 will mean removing the way this
stuff is currently stored in the query cache; it will need to get stored
in the L2 cache in some fashion (probably mapping natural-id to id
values).

-  

Steve Ebersole
Project Lead
http://hibernate.org
steve at hibernate.org

Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole at jboss.com
steve.ebersole at redhat.com


On Wed, 2008-09-17 at 21:43 -0700, Elias Ross wrote:
> On Wed, Sep 17, 2008 at 9:12 PM, Steve Ebersole <steve at hibernate.org> wrote:
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-2879 ???
> >
> 
> If you use Hibernate EntityManager, get the Hibernate Session and use
> Criteria to query by natural ID and the entity was deleted, you end up
> with an EntityNotFoundException. I reported the issue as: HHH-3478
> 
> I have a patch which fixes this problem, but it's a hack. From the issue:
> 
> In StandardQueryCache, there is a "catch" which handles
> "UnresolvableObjectException" but not "EntityNotFoundException"
> 
> catch ( UnresolvableObjectException uoe ) {
>   if ( isNaturalKeyLookup ) {
>   //TODO: not really completely correct, since
>   // the uoe could occur while resolving
>   log.debug( "could not reassemble cached result set" );
>   cacheRegion.evict( key );
>   return null;
> }
> 
> I'm thinking that by keeping an association mapped in the query cache
> -- but I'm thinking that's not the right spot --
> EntityManager/Session.remove() could trigger a removal of any natural
> ID criteria query as well. And so could any update, if the natural IDs
> were mutable. Anyway, you'd get rid of this hack, possibly.