Now that people are considering NOSQL will more people consider no-DB

Re:Now that people are considering NOSQL will more people co... by colanderman on Wednesday August 31, 2011 @07:31PM (#2948039)

The lock doesn't need to just cover one write. It needs to cover the whole transaction. The canonical example is that of incrementing a counter. Replica synchronization aside, without a transaction lock (or some other guarantee of transaction consistency), at some point you will read a counter value which another client is in the middle of updating.

The first "fix" to this that comes to mind is timestamping data, rolling back transactions which try to write having read outdated data. Do extant NoDB systems do this?

[ Parent | on HN ]

Re:Now that people are considering NOSQL will more people co... by wpietri on Wednesday August 31, 2011 @08:49PM (#2948205)

Yes, these approaches provide proper transactions, but the approach is much simpler than you imagine.

Imagine you have a graph of objects in RAM. Say, a Set of Counters. Imagine you want to change the graph by incrementing a counter. To do this create an object, the UpdateCounterCommand, with one method: execute. You hand the command to the system, and it puts it in a queue. When it gets to the top, it serializes the command to disk and then executes it. Exactly one write command runs at a time.

For a real-world example, check out Prevayler. It provides all the ACID guarantees that a database does, but in a very small amount of code.

[ Parent | on HN ]