Yes, the 4 step flow you outline is exactly right.
In our application we started down the road of having different scopes and having the caller to our persistence service specify which scope to use but in the end the complexity had no ROI. We are now using just one transaction scope for everything and we've flipped the setting where the transaction is renewed automatically after a commit. As such, the one transaction scope is always open. This works out well because our user will typically enter a screen, make some changes, and then move on to another screen. If they attempt to leave the screen and the transaction has outstanding changes, we ask if they wish to save or not, and if they say not, we rollback the entire transaction (ie. all the work they decided to walk away from) and the app is ready to accept changes to other domain objects.
So to sum up, we have just one ORM transaction open and it stays open as long as the user in in the application (it's a WPF application). The same approach could be taken with a web app, where the 1 ORM transaction could be kept open as long as the users' session remains alive. Not again that an OpenAccess ORM transaction is NOT THE SAME as a database transaction.
Hope this helps,