Community
Participate
Working Groups
Hello, Inside the AbstractLoadOperation from inside org.eclipse.sphinx.emf.workspace.loading.operations there seems to be a problem. There is a lock set on the editing domain , inside org.eclipse.sphinx.emf.workspace.loading.operations.AbstractLoadOperation.loadModelFilesInEditingDomain(TransactionalEditingDomain, Collection<IFile>, IProgressMonitor) it says editingDomain.runExclusive(..). And the same thing happens again inside org.eclipse.sphinx.emf.util.EcorePlatformUtil.loadResource(TransactionalEditingDomain, IFile, Map<?, ?>) where you can find TransactionUtil.runExclusive(..) The idea is that for the loading part I do not think that this lock is actually needed, if you do consider it as being mandatory could we maybe change the lock on a file and not on the entire editingDomain ? The idea is that we would like to make the loading of the files in a parallel way, but at the moment this is not possible because of these locks. Looking forward to your answer thank you.
(In reply to Martin Raul Reidel from comment #0) > Inside the AbstractLoadOperation from inside > org.eclipse.sphinx.emf.workspace.loading.operations there seems to be a > problem. > > There is a lock set on the editing domain , inside > org.eclipse.sphinx.emf.workspace.loading.operations.AbstractLoadOperation. > loadModelFilesInEditingDomain(TransactionalEditingDomain, Collection<IFile>, > IProgressMonitor) it says editingDomain.runExclusive(..). > > And the same thing happens again inside > org.eclipse.sphinx.emf.util.EcorePlatformUtil. > loadResource(TransactionalEditingDomain, IFile, Map<?, ?>) where you can > find TransactionUtil.runExclusive(..) I don't agree with that this is a problem. EMF Transaction supports nesting of transactions to any depth, see http://www.linuxtopia.org/online_books/eclipse_documentation/eclipse_emf_model_transaction_developer_guide/topic/org.eclipse.emf.transaction.doc/references/overview/eclipse_emf_model_transaction_nesting.html for details. > The idea is that for the loading part I do not think that this lock is > actually needed, if you do consider it as being mandatory could we maybe > change the lock on a file and not on the entire editingDomain ? I don't know what you mean by "lock". Typically, we use two kinds of locks in Sphinx most of the time. One that locks the workspace - or parts of it like projects, files, etc. - and another one that locks the model. The former are represented by Eclipse Platform ISchedulingRules being set on Job or WorkspaceJob instances. The latter are EMF read or write transactions and ALWAYS have the scope of the entire editing domain. > The idea is that we would like to make the loading of the files in a > parallel way, but at the moment this is not possible because of these locks. I agree with that it is not possible to spread model load operations over multiple threads running in parallel with the current design of Sphinx. The problem is that we need to keep the model load operations in read transactions to avoid concurrent write attempts to the model(s) being loaded (which would put them into an inconsistent state). We also need these read transactions because we heavily rely on post commit listeners (which are instances ResourceSetListenerImpl) to trigger all kinds of post load processing once the model load operation(s) is/are finished. The most prominent example for that are refreshes of the UI (Model Explorer, form editor and other). But there is also plenty of other stuff that needs to be done and gets triggered that way. Changing this would entail a profound redesign of the fundamental way Sphinx is working today. I don't say that this is impossible or undesirable (the idea of accelerating the model loading by splitting it over multiple threads running in parallel is actually good and valid), but it is pretty much for sure that such an effort is not a low hanging fruit and requires a rather huge effort.
Closed stale issue before migration
