There seems to be some general confusion here, so to clarify a few things:
The isolation level of a transaction only affects what changes from other transactions are visible. A transaction can always read back data it has modified itself.
If follows that the call to Commit() for the transaction has nothing to with whether or not the NHibernate session that owns the transaction can read back those changes or not. It always can.
However, NHibernate will not modify an already loaded instance. You, as the developer of the model, is responsible for making changes in loaded entities, making sure the model is still valid and consistent with your business rules, and then NHibernate will store the changes in the DB. It is not NHibernate's job to make a part of you model consistent with changes you made in another part.
Reading back before or after the call to Commit() doesn't matter, as NHibernate guarantees that a session will only contain at most one copy of each entity. So when you query for the object you just saved, you will just get back the same, already loaded, unmodified instance.
What matters is if you close the session and open a new session for your query. Then NHibernate will instantiate the object again, and it will reflect the current state of the database. The same effect can be had in the original session if you use Clear() or Evict() on the session (after having called Flush() or Commit()). These methods remove the already loaded instance from the session, so the next time you query for it, the session will create a new instance, which would then of course reflect the current state of the database, as visible from the current transaction.