Hi,

I am considering setting the FlushMode on my session to Commit globally so that I don't get any unexpected flushes occuring midway through a transaction.

What is the consensus on this...are other people doing likewise or using a FlushMode of Auto?

Thanks,

Jason

Disclaimer: I'm a Hibernate user, so take my advice with caution. I was already a Hibernate user in v2(v3 now), and NHibernate is said to be a port for .Net of the v2.

I guess most of the time, you should let the FlushMode.AUTO selected. There's some particular cases where you should use ALWAYS or NEVER (long conversations, disconnecting session between each step of a process for example).

FlushMode.AUTO will certainly act as you'd like : only sending queries when committing OR when a new query is detected to be "result-dependent" of another one which has not been sent yet, so as to have kind of more data integrity.

In NHibernate, what are the possible values of FlushMode?

Possible values are Auto, Commit and Never.

I was using Auto originally, but found that a call to retrieve an object from the Session could trigger the DB updates of the objects that I had been updating as part of the transaction, even though I had not finished my transaction yet.

Setting the FlushMode to Commit seemed to fix the probelm but I was not sure what the repurcussions were for doing that.

Cheers,

Jason

Well, even if the queries are sent to the DB, you shouldn't care. In fact, you're still in a tx context, so even if Hibernate sends an update on a table, a final rollback would unmake it...

Nobody can see the results of these updates if the tx is in a common transaction isolation mode.

Why don't you want these updates not to be flushed? I guess Hibernate is doing it because it thought it could affect the object you're trying to retrieve.

To sum up, there's no problem to use the FlushMode.COMMIT, but then you will have to call refresh() by yourself on objects you know to be dirty.