It seems to me that the a.k.a.'s here are a bit ill-named: pessimistic conflict detection seems like it fits best with lazy data versioning, since it is quicker to detect conflicts and lazy data versioning is well-suited for when you expect more conflicts, since aborts are efficient. Optimistic conflict detection seems like the better strategy with eager data versioning, since using eager data versioning presumes that you will have fewer conflicts (aborts are expensive). (Though I see how, irrespective of data versioning policy, these terms apply logically to the "speed" of detecting conflicts with these two.)
tarabyte
What are different scenarios in which you'd want to use optimistic detection versus pessimistic detection?
POTUS
Without any kind of optimization, I would have thought it was possible for starvation to happen in the optimistic case? What happens when there's multiple threads writing to A while one thread is trying to read this value? Won't it be forced to restart each time?
kayvonf
@POTUS. Good question. That's basically the point of the last bullet "still can have fairness problems". It really has nothing to do with reads. IF there are a bunch of transactions writing A, and we're using a committer wins optimistic strategy, a longer transaction might keep getting aborted because shorter transactions come in and commit. (rolling back all other conflicting transactions.)
fxffx
Pessimistic detection is better when it's expected that many transactions will have conflicting read and write access. Optimistic detection is better when it's expected that there are few conflicts between transactions.
It seems to me that the a.k.a.'s here are a bit ill-named: pessimistic conflict detection seems like it fits best with lazy data versioning, since it is quicker to detect conflicts and lazy data versioning is well-suited for when you expect more conflicts, since aborts are efficient. Optimistic conflict detection seems like the better strategy with eager data versioning, since using eager data versioning presumes that you will have fewer conflicts (aborts are expensive). (Though I see how, irrespective of data versioning policy, these terms apply logically to the "speed" of detecting conflicts with these two.)
What are different scenarios in which you'd want to use optimistic detection versus pessimistic detection?
Without any kind of optimization, I would have thought it was possible for starvation to happen in the optimistic case? What happens when there's multiple threads writing to A while one thread is trying to read this value? Won't it be forced to restart each time?
@POTUS. Good question. That's basically the point of the last bullet "still can have fairness problems". It really has nothing to do with reads. IF there are a bunch of transactions writing A, and we're using a committer wins optimistic strategy, a longer transaction might keep getting aborted because shorter transactions come in and commit. (rolling back all other conflicting transactions.)
Pessimistic detection is better when it's expected that many transactions will have conflicting read and write access. Optimistic detection is better when it's expected that there are few conflicts between transactions.