How do data versioning policies interact with the two modes of conflict detection? It seems that when pairing opposites, (eager versioning, lazy conflict detection) optimizes for infrequent conflicts/fast commits and (lazy versioning, eager conflict detection) optimizes for frequent conflicts/fast aborts. However, pairing the same style of conflict detection and data versioning seems to alleviate the performance downsides of the versioning policy. Beyond that, are certain combinations less practical to implement?

@subscalar if you see the next slide it tells that Eager + optimistic is not practical in Hardware TM systems and the comments give a fair explanation for it.

I'm still a little confused on why optimistic detection could be preferable to pessimistic detection... if we have some sort of conflict, isn't it always better to detect it early rather than later? Especially if we build up a super large undo log.

so there are eager/lazy (aka pessimistic/optimistic) conflict detection and eager/lazy versioning? neither eagers nor lazies have to be paired together