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.
On 03/06/2012 08:41 AM, Alex Snaps wrote:
This has been a recurring subject in the ehcache forum and a source
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<steve(a)hibernate.org> wrote:
> Historically natural-id look ups were accomplished by leveraging
> Criteria queries. Caching was handled through the second level query
> 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?
> hibernate-dev mailing list