Updownquark
commented
3 years ago Actually, it turns out that the first cause is used, not the last. I was misunderstanding the effects I was seeing when I wrote this.
However, there are other reasons for which it would be good to link the chain, esp. the Causable.getCauseLike() method which allows calling code to track the sources of changes.
When an ObservableCollection is locked, the cause is added to a stack. When the lock transaction is closed, the cause is then closed. But if a write lock is obtained nested within a write lock, the two causes are not linked.
This means, e.g. that if the developer locks a collection for an overall transaction and then calls a method in the collection that makes a write lock on itself (many of the default BetterCollection/List/etc. implementations do this), that operation will not be linked to the overall cause, resulting in many events for individual transactions firing when there should be much more event grouping.
All subsequent causes added to the stack via lock(true, cause) should be linked back to previous lock causes in the chain, all the way back to the first cause.
This should also be done with other observable structures.