> There is an existing enhancement request to enlarge the transaction scope
I hope that would be optional/configurable.
Many of our applications use an 'odometer' class which my initial inquiries show will map well to your Id generators (with a few mods in the classes implementing IIdGenerator).
But our applications rely on the behaviour currently exhibited as discussed above.
When a transaction fails in our applications, most of the time(read always), we do not want to rollback the odometer as another user or process may already have taken the next id.
The alternative would be to hold up process B until process A's transaction was completed (either way).
Perhaps I'll change my mind after playing more with client side caching ???