This came as a bit of a shock for me being used to work directly with the database but it makes so much sense when you think about the unit of work pattern implemented by NHibernate/Hibernate.
When you work directly with the database, an update query is immediately sent, and a subsequent select query (within the same transaction) will return the updated data, even though the transaction has not committed yet. But with Hibernate, the query gets “cached” as a unit of work. A subsequent query to retrieve that particular item (by id) will hit the level 1 cache and return the updated item, but a criteria query may not find it, if you just updated the criteria being searched on.
Basically:

ITransaction tx = sess.BeginTransaction();
Account a = new Account();
a.AccountName = "what a cutie";
sess.Save(a);
// now an HQL query "from Account a where a.AccountName='what a cutie',
// will not return the new account!

This is very apparent if you use the profiler and look at the order of the queries… the insert query gets sent after the select one!
In order to get this to work you need to add a call to sess.Flush():


ITransaction tx = sess.BeginTransaction();
Account a = new Account();
a.AccountName = "what a cutie";
sess.Save(a);
sess.Flush();
// now an HQL query "from Account a where a.AccountName='what a cutie',
// will return the new account


Had me pulling my hair for a moment, now I am smacking myself for not seeing the obvious. Too bad NHibernate does not flush automatically before submitting HQL queries. There might be an option for that.