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 [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Wed, 2008-09-17 at 21:43 -0700, Elias Ross wrote: > On Wed, Sep 17, 2008 at 9:12 PM, Steve Ebersole <[EMAIL PROTECTED]> 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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev