Hi,

When I make changes directly to my DB tables, I do not see them reflected in my website which is built on NHibernate. Sometimes this even happens after I rebuild my website project (?!)

How can I control the extent to which NHibernate caches the data from my DB? How does NHibernate implement this caching feature?

Thank you,
urig.

This may not be an NH issue. I have seen this happen on some sites. The problem likes in the Application Pool cache within IIS. When making changes, even simple ASP/HTML changes, we have sometimes had to stop and start the application pool along with the IIS service when deploying updates. We now do this as a standard step in our deployment proess.

NH caches data in two places. The session cache and a second-level cache that you have to configure in your xml file and within each class mapping.

Hi and thanks for your help.

Restarting the IIS Service every time an update is made to the DB is not going to work for me, becuase these updates are routine frequent - The back-end of my NHibernate website is implemented in an independent WebForms app.

Am I correct to understand the the second-level cache is implemented in SessionFactory and is turned off by default?

Am I correct to understand the the first-level cache is implemented in SessionFactory and is turned on by default? How can I control the way in which this cache is refreshed? i.e. set a timeout on specific classes etc.

An observation I've made: When a new record is inserted into the DB (from a non-Hibernate source), it is immediately seen in the website. But when an exisiting record is modified (say an nvarchar value is changed), the update is not seen in the website, even after calls to Session.Flush(). Any ideas?

Thanks again,
urig[/u]

The first level cache is implemented in the NHibernate Session object. If you are seeing new records appear, but not seeing updates on existing records, this could mean you are using a single Session across multiple client requests. Note that the Flush method will not clear objects from the first-level cache. It only synchronises the database state with the in-memory state.

Changing to a Session-per-request approach should solve your issue. If you want to hold onto the session across multiple requests, but would like the state of your object refreshed from the database on subsequent requests, then consider using the Refresh method on the ISession interface. In my opinion, the session-per-request approach is best. You can always detach an object from the NHibernate session, cache it in the ASP.NET session, and then re-attach it on a subsequent request if you need to retain object state between requests.

You're right on target :). I am using a single Session across multiple client requests. In view of your reply and other replies I will switch to a Session-per-Request strategy.

I am still confused about some of the terms you used - What is "in-memory state"? How does it differ from the first-level cache? If Flush() syncs the DB with the in-memory state, doesn't it have to go through both first-level and second-level caches to do this?

In my mind I have the following layer diagram:

DB <--> second level cache <--> first level cache <--> in-memory state

Is this correct?

Your "in-memory" state is the state held by your persistent object instances. The NHibernate Session object represents your first-level cache. The Session object actually just holds references to your persistent object instances. This maintains the "identity scope" within the NHibernate session. That is, all objects representing the same physical database row will have the same object identity (they are the same object). This improves performance as well as subsequent requests for the same database row will be resolved from the first-level cache.

The second-level cache is process-wide. In order to reduce threading issues, the second-level cache actually holds copies of the persitent objects (or more specifically copies of each of their persistent properties).

Flush() will update the database such that all changes made to persistent objects attached to the NHibernate session are reflected in the database. The second-level cache strategy will determine at which point the data in the second-level cache is updated. Of course, this only applies for a read/write cache. NHibernate has two strategies for read/write second-level cache: "read-write" and "nonstrict-read-write". "read-write" maintains "read committed" isolation, whereas "nonstrict-read-write" makes no guarantee of consistency between the cache and the database.

being a beginner, i;ve really learnt some insights of NHibernate from this post. thanks guys. just to share with you people here is another wonderful read about NHibernate Level2 cache