I've been looking to optimize the caching of an application which uses a mutable natural key, an account phone number. Hibernate does not yet support optimized caching of @NaturalId(mutable=false), because of how the current natural ID relies on immutable IDs. The caching associates a QueryKey -> results and it's impossible to evict the QueryKey since the natural keys are embedded in it. One solution I considered was to create an association between a set of natural ID values and "QueryKey". When a query is made with mutable natural keys, an association would be made. This could be done within "StandardQueryCache." And then when an entity is updated or removed, if there are mutable natural keys, Hibernate could locate the query and remove it as well. I'm not sure how I could implement this part. I'm guessing I'd have to add a method to QueryCache to do the removal. public interface QueryCache { ... public void remove(NaturalIdAssocation nia) throws HibernateException; } public class NaturalIdAssociation implements Serializeable { Type type; Set<Object> keys; } Actually, thinking this over, having this removal operation would fix some other issues when non-mutable natural id entities are removed. For instance, HHH-3478, a problem found using EntityManager and natural IDs. Thoughts? _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Wed, Sep 17, 2008 at 9:12 PM, Steve Ebersole <steve(a)hibernate.org&gt; 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.

I really dislike the idea of having a mutable key, am I too extreme? isn't this going to bring you loads of problems? IMHO if it's mutable it is not a key, but of course I don't see the big picture: I'm just curious about the design decision.