major
minor
major
minor
ModelBasedImportConfiguration.handleModelPartChanged() is called from the commit thread in which the model is being modified. The method clears the contents of its caches and repopulates them. In the meantime, the consumer can import changesets in its own thread. In doing so, it queries the caches—which are currently being rebuilt—for the types it is supposed to import. Since the caches are partially empty, they do not contain those types. This is interpreted as: “These types are not being imported.” As a result, these changes are lost. Later, changes that build upon them occur. Due to the inconsistency, these can no longer be imported. TL-Sync is thus permanently broken and no longer transmits anything.
Solution
The public methods of ` ModelBasedImportConfiguration ` and ` ModelBasedExportConfiguration ` have been marked as `synchronized`. One of these is the `notifyUpdate` method, which clears and refills the cache. The others are the methods that use the cache.
As explained in the comments, this is not a complete solution. However, the remaining problem only exists for applications in which the part of the model relevant to TL-Sync is modified at runtime. And so far, this has happened in almost no applications.
Test
No test, as this would be disproportionately time-consuming compared to the solution. A long series of transfers would have to be performed using TL-Sync. During this process, the model would have to be modified. And even then, it would be a matter of chance whether the test fails or “gets lucky” and passes.