With the current plan, if we make updates to history store, the updates are done as part of the application transaction (which means we need one of this txns open in the first place). For this plan to work, we need to put a hack into the commit/rollback code to always treat history store updates as committed.
It will be effective to find alternatives to the above mechanism for two reasons:
- We won't have to do the mentioned hack and treat history store updates special
- We wont have to open a transaction if application txn is not available. We do not want to open a txn just to make history store updates because history store updates do not follow regular transaction semantics also this might interfere with implicit auto transactions that an application might end up opening.