These are the same MVCC semantics I used in Rdb/ELN (1984), Interbase (1986), Firebird (1999), and MySQL Falcon (2006). The implementation, however, is wildly different.
What is the benefit here? As an application developer I need to restart the transaction and hope it's not going to fail again - hence I'm serializing the execution on my own...
On top of all this, when it comes to constraints in relational model they can be complex and the probability of failing transactions is just going to grow. I can see this working only if I start relaxing on my constraints and redirecting transactions in such a way that conflicting transactions are coming to the database already serialized.
What about restarting transactions within NuoDB transparently as soon as an update conflict has occurred?
It's not clear where we're misunderstanding each other, but for clarity NuoDB manages such things as atomic operations and update conflicts without reference to the application. It's an ACID database.
Give us a call or attend a webinar (eg tomorrow) if you want to take a deeper look at it.
Barry Morris, NuoDB