Why does TC try to rollback branch trsaction infinitely after a dirty write?

Sometimes we want to keep the modification that was caused by the dirty write because of business logic. Is it really appropriate to assume that the rollback is retryable?

The only way to stop TC trying rolling back is to modify the data back to the afterImage manually. And this will cause a lost update since we may want to keep the current modification.

Maybe no retrying this type of rollback is better. Let users decide the modification.

Maybe there is a way to prevent dirty writes completely.

Start by tracing the TCC rollback path for dirty writes and how the afterImage is used during retries. Reproduce the reported infinite rollback behavior, then determine whether the expected behavior is to retry, stop retrying, or prevent dirty writes; document the chosen behavior with a focused test.

Written by the indexing model from the issue text.