Why does identity generator break unit of work in nHibernate? What about EF?
===

I understand and accept that the identity generator breaks the unit of work because it requires an insert prior when the transaction should actually commit, described in http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html. I'm aware of the alternatives and why they are better (in relation to the problem at hand, and in general).

The question I have is why the implementation exists as it does, and whether or not these issues affect EF (sheer curiosity). The only real justification I have seen i: ["NHibernate needs the identity because every entity in the session (they are called "persistent entities") needs to be identified. The identity is also normally used to determine if the record already exists in the database (unsaved value)."][1]

Why must it have the value immediately, though? Why can it not defer the INSERT until the commit occurs, the commit, retrieve the value, and update the entities dependent on the returned identity, then insert/update/whatever them as well?

Less important question: does EF suffer from the same issue? I know ISession is a proper UoW implementation; does EF not implement the UoW pattern, or does it have a different way of handling this problem, and if so, what is it?

  [1]: http://stackoverflow.com/a/5234308/981205