They exclude transactions because an ORM maintains a stateful copy of the data on another tier. Once a copy is made of the data, the guarantee that a transacti

They exclude transactions because an ORM maintains a stateful copy of the data on another tier. Once a copy is made of the data, the guarantee that a transaction can succeed or the data remains correct is no longer valid. Considering Fowler spent years pushing ORM's, isn't it a little ironic that his first law, directly from PoEAA is [1] "Don't distribute your objects" yet an ORM encourages distribution via the Unit of Work pattern and local stateful copies. Technically, the only thing that is possible to work for a Object-oriented database is a shared heap, which comes with its own bag of concurrency problems. Relational databases however, have first class concepts within mathematics such as sets and all operations take place in one place against one true source always so transactions can be guaranteed. ORM's are a recent invention and for some of the really big stuff out there, they just don't cut it. I'll post some example cases where transactions and OO falls over if anyone is interested. I've watched enough concurrency and transaction isolation issues raised from ORMs to be intimately aware of them now. [1] http://martinfowler.com/bliki/FirstLaw.html http://martinfowler.com/bliki/FirstLaw.html