> labeling every data update in a transaction with a marker that identifies the nested transaction. > upon ROLLBACK, mark the corresponding nested transaction

> labeling every data update in a transaction with a marker that identifies the nested transaction. > upon ROLLBACK, mark the corresponding nested transaction marker as "to be ignored" > upon any read of the data, skip over any data updates with a (nested) transaction marker known to be ignored. Seems like a good trick. They go on to explain the main performance issue, which seems to be about traversing the ignore list. For long queries a longer ignore list adds constant time overhead to each operation in the transaction. > The expense in this approach is the extra work performed by data reads when there has been at least one ROLLBACK prior. ROLLBACKs add markers to an “ignore list” and cause it to grow, and the performance of each subsequent read operation is slightly slowed down by the increasing ignore list. It would be interesting to get a list of various databases and how they handle transaction logic for rollback operations. If this list also had examples of how the logic plays out in a concrete example then it would be a really useful resource. Engineers could use this list to figure out if their use cases and performance requirements were compatible with their chosen level of transaction isolation properties.