It would be a great to have NH Second-Level cache utilize the new ASP.Net 2.0 SQL Cache Dependency feature. By this, we would be able to place an NH entity in the Second Level cache and keep it there until the underlaying table/row is changed. Using this in plain ASP.Net (without NH) gives an excellent caching scheme for lists of common data (phone area codes, lookup values and other data which is frequently used but infrequently changed. It seems like a must for an ORM system that's targeted to be used in ASP.Net Web applications.
Thinking out loud: (I'm not very farmiliar with the second-level cache provider architecture of NH so maybe I'm way off ) If when NH passes an object/entity to the cache provider the cache provider knows about the cached object's class and assembly, then it should be simple for the cache provider to use NH's meta API to look up the underlaying table/s for the cached entity and just store the item in the ASP.Net cache with an SQL dependancy on the underlaying table.
It would be a great to have NH Second-Level cache utilize the new ASP.Net 2.0 SQL Cache Dependency feature.
By this, we would be able to place an NH entity in the Second Level cache and keep it there until the underlaying table/row is changed.
Using this in plain ASP.Net (without NH) gives an excellent caching scheme for lists of common data (phone area codes, lookup values and other data which is frequently used but infrequently changed. It seems like a must for an ORM system that's targeted to be used in ASP.Net Web applications.
Thinking out loud:
(I'm not very farmiliar with the second-level cache provider architecture of NH so maybe I'm way off )
If when NH passes an object/entity to the cache provider the cache provider knows about the cached object's class and assembly, then it should be simple for the cache provider to use NH's meta API to look up the underlaying table/s for the cached entity and just store the item in the ASP.Net cache with an SQL dependancy on the underlaying table.