3 ms·

"All cores can read simultaneously." Unless someone is writing, of course, in which case you have to worry about isolation. So a single writer would block all

"All cores can read simultaneously." Unless someone is writing, of course, in which case you have to worry about isolation. So a single writer would block all readers, right? "You mean a bug in our code that causes a problem?" No, I mean like "I already wrote some data, but now a constraint has been violated so I need to undo it".

wpietri 15y ago
> So a single writer would block all readers, right? Correct. For the fraction of a millisecond the transaction is executing, anyhow. Since transactions only deal with data hot in RAM, transactions are very fast. > No, I mean like "I already wrote some data, but now a constraint has been violated so I need to undo it". That shouldn't happen, and I've used two approaches to make sure. One is do all your checking before you change anything. The other is to make in-command reversion easy, which is basically the same way you'd make commands undoable. Basically, instead of solving the problem with very complicated technology (arbitrary rollback), you solve it with some modest changes in coding style. Since you never have to worry about threading issues, I've found it pretty easy.
- colanderman 15y ago
  > Correct. For the fraction of a millisecond the transaction is executing, anyhow. Since transactions only deal with data hot in RAM, transactions are very fast. Transactions don't just read and write. They sometimes compute things, like joins, which can take several milliseconds. These computations often must run within the transaction and would thus need to acquire the lock for several milliseconds.
  - wpietri 15y ago
    Do you have a real-world example? Joins haven't been a problem for me, mainly because this approach doesn't constrain you to a tables-and-joins model of the world. With Prevayler, for example, you treat things as a big object graph, so there are no splits to join back up. Of course, it could be that some problem is just computationally intense, but I can think of a number of approaches to lessen the impact of that in a NoDB system.
- freakinjoe 15y ago
  each transaction logged before accepted in RAM, disk is involved here. i never trust batch log commit since, each transaction might affect other operations as well in large applications.

wpietri 15y ago

> So a single writer would block all readers, right? Correct. For the fraction of a millisecond the transaction is executing, anyhow. Since transactions only deal with data hot in RAM, transactions are very fast. > No, I mean like "I already wrote some data, but now a constraint has been violated so I need to undo it". That shouldn't happen, and I've used two approaches to make sure. One is do all your checking before you change anything. The other is to make in-command reversion easy, which is basically the same way you'd make commands undoable. Basically, instead of solving the problem with very complicated technology (arbitrary rollback), you solve it with some modest changes in coding style. Since you never have to worry about threading issues, I've found it pretty easy.

colanderman 15y ago
> Correct. For the fraction of a millisecond the transaction is executing, anyhow. Since transactions only deal with data hot in RAM, transactions are very fast. Transactions don't just read and write. They sometimes compute things, like joins, which can take several milliseconds. These computations often must run within the transaction and would thus need to acquire the lock for several milliseconds.
- wpietri 15y ago
  Do you have a real-world example? Joins haven't been a problem for me, mainly because this approach doesn't constrain you to a tables-and-joins model of the world. With Prevayler, for example, you treat things as a big object graph, so there are no splits to join back up. Of course, it could be that some problem is just computationally intense, but I can think of a number of approaches to lessen the impact of that in a NoDB system.
freakinjoe 15y ago
each transaction logged before accepted in RAM, disk is involved here. i never trust batch log commit since, each transaction might affect other operations as well in large applications.