Community
Participate
Working Groups
The Transaction.OPTION_VALIDATE_EDIT option is not inherited by children of a CompositeEMFOperation. This causes the child operations to execute in their own new transactions, even when reuseParentTransaction is set to 'true', because the options of the child operation are always found to be different from those of the active transaction (which has the validate_edit option set). The creation of unnecessary transactions can have a negative impact on performance (see bug 141051). Please consider enhancing the implementation so that options that don't affect the behaviour of a transaction (like validate_edit) can be excluded from the AbstractEMFOperation#optionsDiffer check, allowing clients to reuse the active write transaction in this case.
Cleaning up after the milestones were all deranged.
Created attachment 118854 [details] A transaction option metadata implementation Attached a patch implementing a pluggable metadata-driven design for handling transaction options. I would very much appreciate some feed-back on this before I commit. I am happy with the design, but it is a change to some fairly core function, so I'd like to get some more eyes on it. The basic idea is to define an interface for a transaction option descriptor that controls the inheritance of transactions and the comparison of option-sets to determine compatibility (the original purpose of this bug). So, we introduce an interface Transaction.OptionMetadata that tells the transaction system: - whether an option is just a tag, that doesn't affect the semantics or inner workings of the transaction - whether an option is inherited by child transactions - what the type and default value of an option are - whether two option-maps have equivalent settings for an option - how to inherit an option A registry maintains these metadata instances at two levels of scoping: globally and locally in a TransactionalEditingDomain (delegating as so many EMF registries do). The global registry initially stores metadata for the options defined by the transaction framework, itself, and clients can add metadata for custom options. The TransactionUtil class provides a method to access the option metadata registry for an editing domain. The AbstractEMFOperation now has no special cases to consider in determining whether the user's transaction options require creating a nested transaction, and the TransactionImpl::inheritOptions(...) method is considerably simplified. Some of the wackier internal options are now neatly pigeon-holed. As this constitutes a generalized solution to the original problem than the fix that was contributed to the Ganymede maintenance branch, I have ported Linda's JUnit test forward and ascertained that this patch solves that problem. Finally, it was discussed previously (in the newsgroup, I think) that a couple of creation methods in the WorkspaceEditingDomainFactory that weren't synchronized as their pals, should be. Since I needed to add a static initializer to this class to register an option, it seemed a good chance to fix that.
I've reviewed the patch and it looks great to me. Thanks! I tested my scenario with the patch. The number of transactions used to complete the scenario decreased from 8413 to 5279 (37%). Overall, it took between 1 and 2 seconds less to complete the scenario (8-16% improvement in speed).
(In reply to comment #3) > I've reviewed the patch and it looks great to me. Thanks! Super. Thanks for the review! I made another change to ensure that the option meta-data registry is thread-safe and to cache lazily-created defaults for unrecognized (client-defined) options. These are now cached locally in the editing domain's registry (not the shared registry). In further testing, I observed that I had missed an option introduced in the resolution of bug 218276 in the 1.2.x maintenance branch. It needed meta-data definition (tag, non-hereditary), as it was falling through the unrecognized option case, and had TODOs to move it in the 1.3 branch. So, these issues are also addressed. Committed to HEAD (1.3 branch).
Fix available in HEAD: 1.3.0.I200812021717.
