Community
Participate
Working Groups
The current session implementation (DAnalysisSessionImpl) is mostly monolithic (despite a few ad-hoc configuration points like setSavingPolicy()), which means the code must always be ready to handle the most generic case. This often prevents optimisations which could benefit a lot of concrete uses, just because we must be ready to handle the 0.1% of "pathological" (or at least uncommon) cases. Beyond performance optimizations, there are often cases in concrete deployment where the fixed choices we make in the core framework does not fit the need of a user/client (the configurable SavingPolicy and ReloadingPolicy, and the setDisposeEditingDomainOnClose() are examples of this). Currently adding any such configurability means breaking the Session API. The goal of this ticket is first to introduce a generic configuration mechanism which will allow clients to customize the implementation of the session for there cases. Possible sources of inspirations: * The EFM way, for example in Resource.save(Map<?, ?> options). * CDO's IOptions (http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/options/IOptions.java) interface and usage pattern (see http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.common/src/org/eclipse/emf/cdo/common/CDOCommonSession.java). * Plain IEclipsePreferences and/or OSGi's org.osgi.service.prefs.Preferences. Steps to move on this: 1. Design and implement the generic mechanism itself. 2. Refactor the existing ad-hoc session mechanisms which should be options into the new mechanism. This should probably be done in parallel with step 1 to guide the design using concrete cases. 3. Leverage the new mechanism to expose some easy/obvious new options, if any low-hanging fruits can be identified (see for example the various optimizations currently guarded by the single "enableUnsafeOptimisations" hidden property.
Important note: making the session's behavior more configurable will have a potentially huge impact on testing: 1. Some tests will only make sense when running with specific options set. This will not be obvious as currently the tests do no make explicit their assumptions. 2. Tests which should work fine with different configurations will only be run with the default one. Ideally, each test should declare its assumptions in how the session is configured, and we should be able to run them with random combinations of all other options (iterating in the configuration space). Note that this problem is not created by the introduction of a options/configuration API. It is already here with the implicit configuration points we already have (e.g. we have tests about session "dirtyness" and workspace synchnronization, but they only run with the default saving policy). This point is probably partially out of scope for this ticket, but should be kept in mind and will probably need to be treated in some way in the future.
In context of this bugzilla, we could manage optionnal unregistration of CrossReferencer at session closing to speed up it.
Moving out of the 4.0 scope for now, along with all the other issues which were there "by default". This does not mean some of these will not be re-integrated at some point, but for now these issues are not part of the roadmap for 4.0. If you feel strongly about this removal from 4.0 and/or are ready to sponsor the corresponding work, feel free to comment.
