Community
Participate
Working Groups
Whenever a child transaction is closed, the parent transaction resumes recording. For that it creates a new ChangeDescription and other overhead associated with ChangeDescriptions. It is noticed that this causes an additional memory consumption of hundreds of megabytes in a complex scenario while the transaction is in progress.
Created attachment 50052 [details] A complete fix to consider for the next release Attached a rather involved change that implements concatenation of ChangeDescriptions, so that when child transactions commit, they append their changes onto the parent's change description, which is then resumed. This drastically reduces the number of change descriptions for complex transactions (as low as 1 when there are no non-EMF changes to include) and allows a large amount of garbage to be reclaimed on-the-fly.
For this release, a smaller change is committed that ensures that child transactions that are not recorded (OPTION_NO_UNDO/OPTION_UNPROTECTED) do not interrupt the parent's change description and generate no additional overhead in change description storage. When an unrecorded transaction is started, the change recorder is "paused" but does not complete its change description. While the unrecorded transaction is in progress, no changes are added to the active description. Recording is resumed when the transaction completes, after which point the active change description may receive updates. This, combined with efforts in the client of the Transaction API to reduce the number of nested transactions (that are recorded), should address the scalability issue sufficiently.
Move to verified as per bug 206558.
