This has been completed and made it into the 4.1 release. There are two parts, a persistence context level cache of PK->NaturalId and NaturalId->PK and a new NaturalIdCacheRegion was added to the caching SPI. The Ehcache provider that ships with Hibernate was updated to support the new region as well. This region ignores the update timestamp cache so it is not invalidated by modifications to the entities. The cache is also populated on insert, update, and load meaning that any time you touch an entity with a naturalId the cache should then be warm for accessing that entity.
-Eric On 03/06/2012 08:41 AM, Alex Snaps wrote: > This has been a recurring subject in the ehcache forum and a source of > misunderstanding by many. > Having the second level cache support these as "first class citizen" > makes total sense to me. Is there some draft of how this would look > like ? Would this be a mapping of natural id to primary key ? > Sorry for not replying any earlier, but I totally oversaw this. Also, > I might be asking the obvious here. Will start looking around the > Loader for natural ids in the meantime. > Do you guys think we can still sync to have the new API in both > Infinispan& Ehcache, or is time running short ? > > On Fri, Jan 20, 2012 at 1:20 PM, Steve Ebersole<st...@hibernate.org> wrote: >> Historically natural-id look ups were accomplished by leveraging >> Criteria queries. Caching was handled through the second level query >> cache. >> >> One of the new things in 4.1 is the dedicated natural-id loading API. >> So the caching will be quite different here. I am a little leery about >> making a breaking changes in 4.1 after all the changes in 4.0 if we can >> avoid it. If we can't we can't. One thought for this was to use a >> SessionFactory scoped "cache" for this in 4.1 and then add a new second >> level cache Region construct for this in 5.0. The *only* benefit is to >> keep the second level cache SPI the same between 4.0 and 4.1. Is that >> worth it? Any thoughts? >> >> >> -- >> st...@hibernate.org >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
