iTwin
Automatically release locks when undoing Txns
Is your feature request related to a problem? Please describe. Locks are held unnecessarily when reversing a Txn. Once you make an edit that requires a lock, the only way the framework will automatically release them is to:
- Push changes
- Undo ALL changes to a briefcase since last sync via
discardChanges - Release the briefcase
Describe the solution you'd like
I would like functions that undo changes to release locks that were acquired during those Txns. For example, TxnManager.reverseTxns and TxnManager.cancelTo should release the locks acquired from those Txns. (perhaps as an optional argument/setting)
Describe alternatives you've considered Manually keeping track of and diffing which locks were created during a specific Txn so that they can manually be reversed on undo.
reverseTxns is revertible operation. We reverse but keep txn on stack which can be reactivated with redo. But cancelTo is permanent operation and we can support release lock for it.
Hmm. That's a good point. I guess we don't have a system to internally try to grab locks again...
Adding it to cancelTo would still be an improvement, but by far the most common use-case I had in mind was the undo command, which I imagine is using reverseTxns.
It could still be useful for a "discard session changes" implementation. Right now, that's implemented using reverseAll, but that could be updated.
The relationship between acquiring locks and modifying data is causal, not strictly coupled. You can acquire a lock without modifying the associated element. However, any modified element is likely to have been locked—though not necessarily with a direct lock. For example, you might acquire an exclusive lock on a parent object and then modify multiple child elements under that scope.
This is why, when working on discardChanges(), I found it simpler to discard all changes and release all locks. Implementing partial discards would require a more sophisticated framework—one that can associate each lock acquisition with a specific transaction. That kind of system would be complex to build and prone to bugs.
Fair enough. I think that sort of managed system has a lot of value, but I understand that's a much larger effort. I will close the issue.
Re-opening this, as we need to identify some solution to locks not being released after undo, and I'm not convinced this can't be done at the platform level
