You described the reasons I stuck with my own psuedo ActiveRecord on top of NHibernate's basic Transaction and Session support. It's called "unit of work" and it makes much more sense to me. We're very specific (for simplicity and sanity) that all HTTP operations to our webapp are autonomous (from the user perspective) and stateless. No multipaged forms, etc.
So every request is given a session and whatever needs to happen as a result of that request is encapsulated in that session. If something goes wrong, that transaction in that session can be reverted. If NHibernate determines that it needs data modified early in the session for something later in the transaction, it handles it behind the scenes. Then an ActiveRecord pattern can be thrown on top of that and you still get CRUD within a "unit of work" context.
So every request is given a session and whatever needs to happen as a result of that request is encapsulated in that session. If something goes wrong, that transaction in that session can be reverted. If NHibernate determines that it needs data modified early in the session for something later in the transaction, it handles it behind the scenes. Then an ActiveRecord pattern can be thrown on top of that and you still get CRUD within a "unit of work" context.
I like it. :)