Designing a robust contention manager is important because you'd like to maximize fairness (i.e. limit starvation) of memory transactions in your system! That being said, because this manager is the single observer for all conflicts (reminding me (just) a little of the bus when talking about cache coherence), it's also important to keep it fast!

Pessimistic detection works well with eager versioning since it does the detection when the memory reference happens.

I think a good way to look at pessimistic detection is to see it as a way to decrease the expected abort time in the case of a conflict. This is the reason that it pairs well with eager versioning: it decreases the expected performance hit of eager versioning's worst case.

I just wanted to point out that with pessimistic detection the livelock problem that occurs due to two transactions having the same write set can be avoided with the use of ticket locks where each transaction is assigned a ticket and the commits are done according to the assigned ticket; this system would need to be implemented by the contention manager.