We are using an nHibernate session management utility similar to the one in the Mcaffrey NHibernate Best Practices article.

We have a persistent object (A) that has a collection of persistent objects (B). Object A has a complex validation process it must pass in order to save. But if we create a new B, add it to A and pass A to the validation process and it fails and throws an exception, B is still saved. (.Save(B) is never called)

Is this because the session-in-view pattern is closing the session after the exception is thrown and the request completes and flushes the session? If so, what is the best way to handle this?

When this sort of thing happens to me, it's usually because my validation process performs a query on the A object. This is a very common situation: if you want to validate A, you often need to know about other things in the database that refer to A. The problem is that when hibernate notices that you're querying relative to A, and A is dirty in the session, it'll flush A back to the DB so that the query works with the most up-to-date data.

The way to handle this is to start your save transaction before starting your validation. That way, when validation fails, you can rollback and undo the auto-flushed changes.

Thanks for the quick response. I'll give that a try in the morning.

I'm not sure if this is the best way to do it or not, but, you can also change the value of ISession.FlushMode. The default is Auto which flushes before queries. If you set it to Commit, it will only flush upon ITransaction.Commit().