3 ms·

I'm lost here as well. Let's imagine I have COUNTER table of one numeric field VAL. All I do in transactions is: update COUNTER set VAL = VAL + 1 Let's assume

I'm lost here as well. Let's imagine I have COUNTER table of one numeric field VAL. All I do in transactions is: update COUNTER set VAL = VAL + 1 Let's assume the initial state is one entry with VAL = 0. If I run the update statement in two concurrent transactions I'd expect the result to be 2 when both transactions complete. However, I don't understand how that can be achieved without serializing those transactions.

jimstarkey 15y ago
The system recognizes that two concurrent transactions are trying to update the same record. If the first commits, the second will return an update conflict. The application can then restart the transaction. 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.
- julochrobak 15y ago
  thank you for the explanation. I'm really sorry but I don't agree that this is the way going forward. You claim that serializability is not needed to achieve consistency. I agree up to the point that it's only possible if the conflicts are recognized and transactions aborted. 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?
  - bsmorris 15y ago
    We'd be happy to address these issues if you are interested. 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

jimstarkey 15y ago

The system recognizes that two concurrent transactions are trying to update the same record. If the first commits, the second will return an update conflict. The application can then restart the transaction. 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.

julochrobak 15y ago
thank you for the explanation. I'm really sorry but I don't agree that this is the way going forward. You claim that serializability is not needed to achieve consistency. I agree up to the point that it's only possible if the conflicts are recognized and transactions aborted. 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?
- bsmorris 15y ago
  We'd be happy to address these issues if you are interested. 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