I have some doubt...
I do exactly as the documentation said
but I'm working on views (this sould be the same, right?)

I've added the recompiled DLLs to my ASP.Net 2.0 project
NHibernate.Caches.Prevalence.dll or NHibernate.Caches.SysCache.dll

adding the lines in web.config
<add key="hibernate.cache.provider_class" value="NHibernate.Caches.Prevalence.PrevalenceCacheProvider, NHibernate.Caches.Prevalence" />
<add key="relativeExpiration" value="300" />

Added <cache usage="read-write|nonstrict-read-write|read-only"/> (just after <class>) in the mapping of the entities I want to cache, i.e.:

<class name="DataObjects.Admin.VPc, DataObjects.Admin" table="ADM.V_PC">
<cache usage="read-only" />

<id name="IdPc" column="ID_PC" type="Decimal" unsaved-value="0">
<generator class="assigned" />
</id>

<property column="ID_EXP" type="Decimal" name="IdExp" />

I was careful. Caches are never aware of changes made to the persistent store by another process (though they may be configured to regularly expire cached data). As the caches are created at the SessionFactory level, they are destroyed with the SessionFactory instance; so I kept it alive in a static class that handles all use of my NHibernate object, as this:

namespace DomainObjects
{
public static class AccessToMyView
{

static ISessionFactory factory;

static AccessToMyView()
{
Configuration cfg = new Configuration();
cfg.AddClass(typeof(DataObjects.Admin.VPc));

factory = cfg.BuildSessionFactory();

//ITransaction transaction;
//transaction = session.BeginTransaction();
}

public static List<VPc> GetAll()
{
List<VPc> resultats = new List<VPc>();

ISession session;
session = factory.OpenSession();
System.Collections.IList temp;

System.Collections.IDictionary dic = factory.GetAllClassMetadata();

temp = session.CreateCriteria(typeof(VPc)).List();

session.Close();

foreach (VPc item in temp)
{
resultats.Add(item);
}

return resultats;
}

(note , I prefer returning a Generic list than an IList)

I'm using VS2005 and absolutely all librairies have been recompiled to frmwk 2.0
my project as an N-tiers architecture.

results:

using NHibernate.Caches.SysCache.SysCacheProvider: no better results than desactivating it. SQL profiler show that the sql query is still send.

using NHibernate.Caches.Prevalence.PrevalenceCacheProvider: worse that ever! display my page is 2x slower.

in another hand, I try as a second chance to use the ASP.Net 2.0 cache mechanism and it is working wery well

I've done further investigation
and add some breakpoint in NHibernate libs and Syscache

and any method Get (from Syscache.cs or ReadOnlyCache.cs) is never called.

However, BuildCache is called at first load.

Weird... I'm sure have missed something in my config or usage.

and I found something more weird in SettingsFactory:: public static Settings BuildSettings( IDictionary properties )
{ ....
bool useQueryCache = PropertiesHelper.GetBoolean( Environment.UseQueryCache, properties );
... }
(line 120 SettingFactory.cs)

that return false!!!!

of course cache won't work!!

you have to add the line
<add key="hibernate.cache.use_query_cache" value="true"></add>
in your config file

this is not in the documentation :evil: grrrrrr

but it's still not working beceause queryParameters.Cacheable returns fasle in Loarder.cs line 1278 (method protected IList List )

Use IQuery.SetCacheable(true)

thanks.
but I think ICriteria SetCacheable is better for my example.

here's what I coded:

ICriteria ic = session.CreateCriteria(typeof(VPc)).Add(Expression.Eq("CodeUnique", CodeUnique));

ic.SetCacheable(true);

temp = ic.List();

I works fine... almost
the first request is -as expected but too much IMHO- longer. far away longer than without using the cache.
the number of rows returned is round 150.

when I try antoher request
ICriteria ic = session.CreateCriteria(typeof(VPc));
ic.SetCacheable(true);
temp = ic.List();

so, no filters here, then the request return almost 25000 rows.

Works fine again but (always a but) it has a mitigated performance. When displaying results in a paged asp:GridView, each refresh or change of page in the Grid takes 2 seconds.
I use for the moment "NHibernate.Caches.SysCache.SysCacheProvider"
I'll continue my test with NHibernate.Caches.Prevalence.PrevalenceCacheProvider, and tell you.

I'm about to do load test now. And compare NHibernate cache with ASP.Net 2.0 cache.

may the documentation be updated for all the users, please ?

let them know about the <add key="hibernate.cache.use_query_cache" value="true"></add> section in their config files
and the ICriteria.SetCacheable and IQuery.SetCacheable usage

Yeah I've messed around with the NHibernate.Caches.Prevalence.PrevalenceCacheProvider. My integration tests went from taking 11 seconds to taking 60 seconds.
Also when I set the prevalenceBase option I keep on getting errors about command files already existing.

tadaaaa!
results form *my* load test

some good and bad news

this is only one test, more should be made to be more accurate. let's say it's a first sight.
this is extremely raw results,
formated as this (MS Web Stress tool used here)
Page Hits TTFB Avg TTLB Avg Auth Query
===============================================

here are the values:

With ADO.Net , with and without ASP.Net cache


GAND /TestChargeNHIbernate/ado/ 9 71.56 75.00 No No

page with 150 rows in GridView, with pagination without cache

GAND /TestChargeNHIbernate/ado/ 10 54.40 54.50 No No

page with 150 rows in GridView, with pagination, changing page, without cache
POST /TestChargeNHIbernate/ado 11 3.91 53.36 No No


page with 150 rows in GridView, without pagination with cache
GAND /TestChargeNHIbernate/ado/ 17 9.59 10.94 No No

page with 150 rows in GridView, with pagination with cache
GAND /TestChargeNHIbernate/ado/ 20 34.60 34.85 No No

page with 150 rows in GridView, with pagination with cache, changing page

POST /TestChargeNHIbernate/ado 13 0.00 53.77 No No



page with 650 rows in GridView, without pagination without cache
POST /TestChargeNHIbernate/ado 19 1795.84 30007.95 No No

page with 650 rows in GridView, with pagination without cache
POST /TestChargeNHIbernate/ado 220 0.37 55.83 No


page with 650 rows in GridView, with pagination, changing page, without cache
POST /TestChargeNHIbernate/ado 220 0.11 51.02 No No
POST /TestChargeNHIbernate/ado 196 0.07 57.77 No No

page with 650 rows in GridView, without pagination with cache
POST /TestChargeNHIbernate/ado 11 27.09 15539.18 No No

page with 650 rows in GridView, with pagination with cache
POST /TestChargeNHIbernate/ado 211 0.24 0.88 No No

page with 650 rows in GridView, with pagination with cache, changing page
POST /TestChargeNHIbernate/ado 146 0.02 1.19 No No
POST /TestChargeNHIbernate/ado 131 0.36 2.76 No No


page with 25000 rows in GridView, without pagination without cache
POST /TestChargeNHIbernate/ado 16 2394.44 82107.75 No No

page with 25000 rows in GridView, with pagination without cache
POST /TestChargeNHIbernate/ado 126 51.39 348.05 No

page with 25000 rows in GridView, with pagination, changing page, without cache
POST /TestChargeNHIbernate/ado 121 8.62 9.26 No No
POST /TestChargeNHIbernate/ado 92 15.64 786.80 No No


page with 25000 rows in GridView, without pagination with cache
POST /TestChargeNHIbernate/ado 17 852.71 853.29 No No

page with 25000 rows in GridView, with pagination with cache
POST /TestChargeNHIbernate/ado 109 42.86 4157.79 No No

page with 25000 rows in GridView, with pagination with cache, changing page
POST /TestChargeNHIbernate/ado 87 10.22 140.85 No No
POST /TestChargeNHIbernate/ado 78 30.35 756.18 No No

notes
ADO.Net with SqlDataSource is really fast. Cache is somandimes useless, viewing with a GridView is a good factor of efficiency, but first display is painfull.

with NHibernate objects, without cache NHibernate, nor cache ASP.Net 2.0
page with 150 rows in GridView, without pagination
N.A
page with 150 rows in GridView, with pagination

GAND /TestChargeNHIbernate/VueA 3612 50.89 217.53 No No
page with 150 rows in GridView, with pagination, changing page
POST /TestChargeNHIbernate/Vue 3613 2.67 124.25 No No
POST /TestChargeNHIbernate/Vue 3612 1.44 140.64 No No
POST /TestChargeNHIbernate/Vue 3610 1.58 162.84 No No
page with 650 rows in GridView, with pagination
GAND /TestChargeNHIbernate/VueA 94 140.15 489.53 No No

page with 650 rows in GridView, with pagination, changing page
POST /TestChargeNHIbernate/Vue 94 11.84 515.03 No No
POST /TestChargeNHIbernate/Vue 94 6.23 509.80 No No


page with 25000 rows in GridView, with pagination
POST /TestChargeNHIbernate/Vue 6 104.17 42649.33 No
page with 25000 rows in GridView, with pagination, changing page
No
POST /TestChargeNHIbernate/Vue 10 3.80 39028.50 No No
POST /TestChargeNHIbernate/Vue 10 8.80 31626.20 No No
POST /TestChargeNHIbernate/Vue 10 0.00 24158.80 No No
POST /TestChargeNHIbernate/Vue 7 0.00 32371.14 No No
POST /TestChargeNHIbernate/Vue 2 0.00 14752.50 No No



notes
NHibernates objects are rather good; however they induce a certain overhead, especially for the amount of time needed to complete the page rendering. Server response time is still light.

Warning: performance is terrible when requesting a large amount of rows.

with NHibernate objects, with cache NHibernate (sysCache), without cache ASP.Net
page with 150 rows in GridView, without pagination
POST /TestChargeNHIbernate/Def 9 0.11 9.00 No No

page with 150 rows in GridView, with pagination
GAND /TestChargeNHIbernate/VueA 10 21.90 21.90 No No

page with 150 rows in GridView, with pagination, changing page
POST /TestChargeNHIbernate/Vue 10 0.00 17.20 No No

page with 650 rows in GridView, with pagination
N/A
page with 650 rows in GridView, with pagination, cght de page
GAND /TestChargeNHIbernate/VueA 94 24.89 489.55 No No
POST /TestChargeNHIbernate/Vue 94 12.20 515.37 No No
POST /TestChargeNHIbernate/Vue 94 11.14 513.59 No No
POST /TestChargeNHIbernate/Vue 94 7.27 509.84 No No

page with 25000 rows in GridView, with pagination
POST /TestChargeNHIbernate/Vue 71 13.46 6653.52 No No
POST /TestChargeNHIbernate/Vue 40 33.33 14720.10 No No

page with 25000 rows in GridView, with pagination, changing page
(10 users)
POST /TestChargeNHIbernate/Vue 15 17.93 1316.20 No No
POST /TestChargeNHIbernate/Vue 15 11.27 1336.87 No No
POST /TestChargeNHIbernate/Vue 15 12.13 1337.67 No No

(100 users)
POST /TestChargeNHIbernate/Vue 40 9.13 6853.85 No No
POST /TestChargeNHIbernate/Vue 40 4.05 7457.13 No No
POST /TestChargeNHIbernate/Vue 23 8.61 1073.30 No No
POST /TestChargeNHIbernate/Vue 22 10.05 4195.55 No No

notesEffects of the NHibernate cache are obvious for large data retrieval only. But we

It seems most of the time is spent getting objects OUT of the second level cache. I think it is because it has to reconstruct an object from a list of porperty values.

I am going to play with using a dynamically generated assembly to replace this and see if it helps. I've got a lot of reading up about System.Reflection.Emit to do.