NuoDB Conflict Management

Continuing previous post on NuoDB, December there was another technical session on NuoDB. I had few questions on conflict management as well. I have captured my understanding in below notes.

 

Does Readers block writers ?

Every new update is stored as new version. There are no updates to existing records. This way reads do not block writes.

 

Write / Write Conflicts ?

Only after recent Write operation is completed, the next write operation would be performed

 

How long does these versions exist in memory ?

Thanks to Jim for commenting on post. He has provided the answer

NuoDB has a garbage collector that runs around deleting inaccessible record versions

Webinar Notes

• Bottleneck of Current OLTP Databases - Lock management, this is synchronous, related queries would be blocked until Data is committed, Managing the Table structures on the Disc along with supporting ACID compliance. Again this depends on so many factors isolation levels, locks set.
• NuoDB - MVCC based. Asynchronous mechanism. Conflict management related questions listed above provides clarity on implementation

Brokers - Load Balancing
Archive Manager - Stores data as Key Value Pair

Transaction Manager - Diskless.

• The process of performing a transaction includes
• Broker Notifies Transaction Manager for Transaction to be performed
• Fetch the required ATOMS from Archive Manager
• Load the Data into Transaction Manager
• Perform the transactions
• Pass it to Archive Manager and commit in DB

Session also covers brief overview of Elasticity, Virtualization, High Availability support of Nuo-DB. Benchmark results against Mysql results are a good start and a compelling reason to try out NuoDB

 

Happy Learning!!