Syntetic primary keys are widely used and they make sense. In some circumstances they are slow, let me describe an example. If you have a user management for a web site. The natural key might be the login name. The syntetic key might be a user identifier (number). If you validate a user you have to go to the database even if your user is cached because you don't know the primary key.
To avoid it I implemented an LRU cache with a map to resolv the natural key -> primary key. I think it would be be a better solution if Hibernate would do that. All you need is to tag the attribute as unique. Hibernate could use unique attributes to provide additional indices for the cache.
Is something planned like that for release 3?

This doesn't make much sense, since you would have to hit the databse in any case to do this validation. The cache only has a subset of data.

Actually it can make sense, when resolving associations with property-refs, and in a future version of Hibernate, we *may* support cache by natural key (I havn't thought through all performance implications yet) but I agree that in this particular case it doesn't make sense.

You have to make sure at *some* stage that the user exists, which requires a trip to the db. You would then cache the detached User object in the HttpSession, so you will always know its surrogate key from then on.

I don't think a DB roundtrip is necessary. Why not first ask the cache if the object is cached and only if it's not cached you need a DB roundtrip. This works seamless at least for data you are the only modifier.

Did this feature make it in to 3.0?

no

Thanks for the quick response! I'd like to outline my scenario and why I would like this feature, for posterity. Maybe a justification to include in 4.0.

I dutifully used surrogate keys as the primary identifiers for all my objects, as recommended in the wonderful book Hibernate in Action.

Our web site is internationalized, and one of the objects is a TranslationDomain, which has a property "code" that identifies it, that is also a natural key (unique=true). The web view layer makes calls to the service layer getTranslationDomainByCode("LoginPage") and getTranslationDomainByCode("PurchasePage"), etc, which it can then query by Locale to get the proper localized String to display.

These TranslationDomain objects are prime candidates for caching, since they rarely change. The problem is, the view layer only knows the codes (i.e. the natural keys), so it's missing the cache hit each time.

Of course, the view layer can maintain its own local cache of Translations, but... the Translations WILL change sometimes, (i.e., if we find a typo and want to correct it). So that's where the cache timeout provided by an ehcache would be awfully handy so we don't have to restart the web server to have the translation take effect! :-)

So, in closing, unless I'm missing an obvious solution here, it would just be really nice if hibernate could somehow use natural keys to identify cache hits.

Thanks for listening!