Community
Participate
Working Groups
The TransactionalEditingDomain (certainly) comes with transactional handling for changes of the model. CDO also comes with a transactional API. On GMF-based Dawn editors, where both worlds are combined, this often leads to problems. In this case I think having two transaction mechanisms is at least unnecessary. Having a CDO-based TED would be a much better solution. So we should provide a *CDOTransactionalEditingDomain* which implements the TransactionalEditingDomain interface with CDO related technologies.
I don't think this makes sense in general, because in spite of the similarity in the terms, EMF tx's and CDO tx's serve purposes that are mostly orthogonal. What is proposed here only makes sense for apps in which a locally atomic in-memory operation must upon completion be atomically committed to the server. Apparently Dawn works this way? But even then it's awkward because a TxEditingDomain is supposed to manage *local* concurrency and support undo/redo, functionalities that aren't easily mappable to CDO tx's. So to me this seems more like support for Dawn-specific behavior rather than something that should be part of the CDO core. > On GMF-based Dawn editors, where both worlds are combined, this often > leads to problems. What kind of problems? For the past 2 years I've been on a project that uses both technologies in parallel, and I think it mostly works well.
(In reply to comment #1) > But even then it's awkward because a TxEditingDomain is supposed > to manage *local* concurrency Do you mean by "local" that a commit on a TED does not lead to any Resource.save() being called? I'm not a TED expert but I doubt that. > and support undo/redo, functionalities I think undo/redo is not TED specific, but rather a general EditingDomain feature (command stack). So I guess Martin does not intend to change anything about this particular aspect. -- Generally I tend to think that we do not need a CDO-specific TED, but one that just bypasses all transactional handling, so that in combination with CDO no extra transactionality is added on top. I'd vote for renaming the bugzilla and the new TED accordingliy (e.g. NonTransactionalEditingDomain) and move the bugzilla to EMF Transaction. But until we prove that it works we should keep it here ;-)
(In reply to comment #2) > Do you mean by "local" that a commit on a TED does not lead to any > Resource.save() being called? Yes that's what I mean. There isn't even an explicit #commit on the TED interface, nor on its command stack, nor does the standard implementation (AbstractTransactionalCommandStack/TransactionalCommandStackImpl) call resource.save() anywhere. As we discussed on Skype, TED's aren't concerned with persisting state after a commit. They are only concerned with making in-memory operations on the ecore model (i.e. EMF Commands) atomic. That is, if a complex EMF command is executed on a TED and fails somewhere half-way during execution, the entire EMF command is rolled back. (And in addition the TED manages the possibly concurrent execution of such atomic ops.) > I think undo/redo is not TED specific, but rather a general EditingDomain > feature (command stack). That's true. > So I guess Martin does not intend to change anything > about this particular aspect. OK, but undo is an awkward concept if the change was already persisted...
Caspar, Thanks for the info! Do you, as an expert in both worlds, think that CDO substitutes for both aspects (CDOTransactions for thread isolation and CDOSavePoint.rollback for undo) would be adequate and not too fat? BTW CDOSavepoint.rollForth() would be an interesting feature for CDO, too, eh?
Casper, some oft he problems mentioned earlier (or actually not mentioned) came from a wrong usage of the TED. But what I am concerned about is that when a resource is loaded on a TED it attaches a TransactionChangeRecorder to every object in the resource by walking through the whole tree. In this case all objects are loaded from the repository (as far as I could see). This could be troublesome for bigger repositories. But I am neither an expert on the TED. So, what are your experiences in this area?
Compare bug 247141.
Eike, thanks for the interesting bugzilla. As mentioned there, providing an own CDO TransactionChangeRecorder could solve the problem. But as far as I know there is now way to plug in an own TCR to an existing TED. It will be instantiated in the *createChangeRecorder()*. To insert an own implementation we ne to ask the TED guys to make it possible to insert an own TCR implementation or to subclass the TED (something like a CDOTransactionalEditingDomain) and override *createChangeRecorder()* (This part of what this bugzilla is about). Caspar, I agree with you that the internal Command execution based transaction of the TED and our transactions are slightly different. Insofar my initial proposal might be not completely correct. But the second thing I am worried about with the TED is the *runExclusive()* method. In fact, currently I am facing deadlocks if I am running SWTBot tests on Dawn. Which means there are different technologies involved (CDO/Legacy, Dawn, GMF/TED, SWTBot), so the TED might not take part in this. Unfortunately, if I am going to debug the problem the deadlock do not occur so I can?t se who is causing it ? Caspar, as a CDO/TED expert, have you ever experienced deadlocks when using both combined? Do you see a potential risk when using the existing implementation of the TED with CDO? Just to make sure we are on the same page. If we are not concerned about deadlocks (if Caspar has agreed that those are unlikely to happen), we are just talking about is the change of the adaption mechanism for the TCR, right?
> Do you think that CDO substitutes for both aspects (CDOTransactions > for thread isolation and CDOSavePoint.rollback for undo) would be > adequate and not too fat? No, not adequate and yes, too fat if you're talking about substituting rollbacks for undos, since an undo is supposed to only be a rollback of an in-memory operation. But too light if you're talking about substituting CDO's thread isolation for the much stronger concurrency control afforded by EMF tx's. To elaborate on the latter (concurrency control): The standard implementation of a TED (i.e. a TEDImpl) simply serializes the execution of EMF Commands (provided that EMFPlugin.IS_ECLIPSE_RUNNING == true; otherwise it defaults to no concurrency control at all). Concurrent execution of EMF commands is completely prevented by means of the transactionLock', see TransactionEditingDomainImpl.java. AFAICS, CDO only locks the entire view for the duration of an elementary FSM operation. This doesn't prevent composite ops (i.e. operations consisting of several elementary FSM ops) from being processed concurrently. (And note that even a basic EMF op such as #add involves multiple FSM ops.) > have you ever experienced deadlocks when using both combined? Do you > see a potential risk when using the existing implementation of the > TED with CDO? If the app programmer uses the default TED implementation consistently (which it pretty much enforces unless someone intentionally hacks around it), then I don't see how the combined use of the TED and CDO tx's could cause a deadlock. But of course the picture complicates dramatically if you write a custom TED implementation that tries to be smart about allowing some concurrency -- something I've never tried. > TransactionChangeRecorder ... This could be troublesome for bigger > repositories Yep, it is. > we are just talking about is the change of the adaption mechanism > for the TCR, right? Yes.
(In reply to comment #8) > > Do you think that CDO substitutes for both aspects (CDOTransactions > > for thread isolation and CDOSavePoint.rollback for undo) would be > > adequate and not too fat? > > No, not adequate and yes, too fat if you're talking about substituting > rollbacks for undos, since an undo is supposed to only be a rollback > of an in-memory operation. Sorry, that was a mindfart. YES, CDOSavePoint.rollback *could* sensibly be mapped to TED.commandStack.undo, at least from a user perspective. It might get messy on the implementation level though... the savePoints mechanism is pretty complex and obscure (to me anyway).
Moving all open enhancement requests to 4.1
Hi, In our application which works with local XMIResource as well with remote CDOResource in a same ResourceSet, we use GMF then EMFT to update our resources content, and CDO with passive updates. To avoid IllegalStateExecption of the default TransactionChangeRecorder, we override the default TransactionalEditingDomain to provide a TransactionChangeRecorder which filter CDODeltaNotification, but our application as working also with local resources has some adapters which when being notified of changes do somes other changes on the models (XMIResource for example) assuming that a EMFT transaction is currently active in the current thread, we have also somes ResourceSetListeners which are responsible to update the model on EMFT transaction commit, but on remote changes reception the adapters trigger somes standard ENotificationImpl which can't be filtered by our TransactionChangeRecorder and throws a IllegalStateException and our ResourceSetListeners are not called at all because of missing active EMFT transaction. To fix these issues, we have had the idea to call a InternalTransactionalEditingDomain.startTransaction() at CDOSessionInvalidationEvent event reception and commit this created EMFT transaction on CDOViewAdaptersNotifiedEvent event reception to have a active transaction for adapters and have ResourceSetListeners called on remote changes reception. But we can't do that because a EMFT transaction can be associated to a single thread and CDOViewAdaptersNotifiedEvent event is sent by a different thread of than the CDOSessionInvalidationEvent event. Indeed we see in CDOSessionImpl.invalidateView() that InternalCDOView.invalidate() is called with the parameter async at true to have the invalidation step done in a InvalidationRunnable. Do I have a mean to execute the invalidation in sync?
What do you think about this use case? :)
(In reply to comment #11) > Hi, > > In our application which works with local XMIResource as well with remote > CDOResource in a same ResourceSet, we use GMF then EMFT EMFT what? > to update our resources > content, and CDO with passive updates. To avoid IllegalStateExecption of the > default TransactionChangeRecorder, we override the default > TransactionalEditingDomain to provide a TransactionChangeRecorder which filter > CDODeltaNotification, but our application as working also with local resources > has some adapters which when being notified of changes do somes other changes > on the models (XMIResource for example) assuming that a EMFT transaction is > currently active in the current thread, we have also somes ResourceSetListeners > which are responsible to update the model on EMFT transaction commit, but on > remote changes reception the adapters trigger somes standard ENotificationImpl > which can't be filtered by our TransactionChangeRecorder and throws a > IllegalStateException and our ResourceSetListeners are not called at all > because of missing active EMFT transaction. Sorry, but all this totally confuses me ;-( > To fix these issues, we have had > the idea to call a InternalTransactionalEditingDomain.startTransaction() at > CDOSessionInvalidationEvent event reception and commit this created EMFT > transaction on CDOViewAdaptersNotifiedEvent event reception to have a active > transaction for adapters and have ResourceSetListeners called on remote changes > reception. But we can't do that because a EMFT transaction can be associated to > a single thread and CDOViewAdaptersNotifiedEvent event is sent by a different > thread of than the CDOSessionInvalidationEvent event. Indeed we see in > CDOSessionImpl.invalidateView() that InternalCDOView.invalidate() is called > with the parameter async at true to have the invalidation step done in a > InvalidationRunnable. Do I have a mean to execute the invalidation in sync? In sync to what?
EMFT == EMF Transaction Having a ResourceSet with XMIResource and CDOResource, CDO manages the transaction for shared resource and EMFT manages the transaction for XMIResource. With CDO having passive updates, the InvalidationRunnable updates the local CDOResource content according to remote changes, but like we use EMFT, all model changes must be integrated in a org.eclipse.emf.transaction.Transaction (a EMFT Transaction being associated to a current thread). With CDO when receiving remote changes, we receives a CDOSessionInvalidationEvent event before the InvalidationRunnable launch and we receives a CDOViewAdaptersNotifiedEvent event at the end of the InvalidationRunnable execution. I don't understand why these events are not sent in the same thread, if sent in the same thread we could use a EMFT Transaction to integrate these remote changes (and have all our pre/post commit listener called).
(In reply to comment #14) > EMFT == EMF Transaction For me EMFT == EMF Technologies project :P > Having a ResourceSet with XMIResource and CDOResource, CDO manages the > transaction for shared resource and EMFT manages the transaction for > XMIResource. > With CDO having passive updates, the InvalidationRunnable updates the local > CDOResource content according to remote changes, but like we use EMFT, all > model changes must be integrated in a org.eclipse.emf.transaction.Transaction > (a EMFT Transaction being associated to a current thread). This sounds incompatible with the way remote invalidation works in CDO. Why is an EMF Transaction necessarily associated with a thread? Isn't that a little inflexible? > With CDO when receiving remote changes, we receives a > CDOSessionInvalidationEvent event before the InvalidationRunnable launch and we > receives a CDOViewAdaptersNotifiedEvent event at the end of the > InvalidationRunnable execution. I don't understand why these events are not > sent in the same thread, if sent in the same thread we could use a EMFT > Transaction to integrate these remote changes (and have all our pre/post commit > listener called). No. The "same thread" you're referring to is really a background thread already. In the end this event is I/O triggered and the only way to handle it in the main/current thread is to do all the I/O in the main/current thread. Well, hypothetically there's an alternative: CDO's background thread could just queue up the invalidation event for manual execution. The application would have to call sth. like view.processInvalidations() repeatedly. I think that would be a nice addition to the framework, but not a small thing! Not sure if this helps, but you can also control the time of invalidation processing by holding the monitor lock of the view. But when the invalidation runner can acquire this lock it will do its work in the background thread.
Ok I understand a little better :) The CDOSessionInvalidationEvent is a session event and not a CDOView event and is sent just after the local revisions updates on remote changes reception. for CDOView we have the CDOViewInvalidationEvent and CDOViewAdaptersNotifiedEvent sent in the InvalidationRunnable, the first is called after the invalidate call and the second after the CDODeltaNotifications sending. In fact we could listens the CDOViewInvalidationEvent event to open a EMFT Transaction, but it is the CDOView.invalidate() method which apply really the changes, in addition in case of invalid cross references to resolve (with a CDOTransaction) some ENotification will be sent before the CDOViewInvalidationEvent sending. Finally we needs a event to be sent just before the CDOView.invalidate() method calls to capture all remote changes with their Notifications sent.
Created attachment 216186 [details] A test case with no specific TED to integrate remote changes in a EMF Transaction Hi, I have attached a testcase showing our use of CDO with EMF Transaction, mixing CDOResource and XMIResource, the EMFTAwareInvalidation class allows to integrate remote changes in a EMFT Transaction and avoid the "java.lang.IllegalStateException: Cannot modify resource set without a write transaction" exception from the TransactionChangeRecorder and have our precommit listener (LocalResourceUpdater) called even on remote changes. P.S. the test case throws org.eclipse.net4j.util.container.FactoryNotFoundException: Factory not found: org.eclipse.net4j.connectors[tcp] like the Bugzilla_329786_Test in the test suite (which is not launched on hudson.eclipse) and I don't understand why, but the testcase is sufficiently clear (for me :)) to understand my usecase. And we can see that the EMFT Transaction opening is done on the InvalidationEvent event reception just after the remote changes integraton which can be a issue if we have a precommit listener which throws a RollbackException to revert all remote changes integration. Then we needs a event juste before the AbstractCDOView.invalidate() call in CDOViewImpl.doInvalidate().
Created attachment 216462 [details] A test case with no specific TED to integrate remote changes in a EMF Transaction Hi, I have attached a testcase showing our use of CDO with EMF Transaction, mixing CDOResource and XMIResource, the EMFTAwareInvalidation class allows to integrate remote changes in a EMFT Transaction and avoid the "java.lang.IllegalStateException: Cannot modify resource set without a write transaction" exception from the TransactionChangeRecorder and have our precommit listener (LocalResourceUpdater) called even on remote changes. P.S. the test case throws org.eclipse.net4j.util.container.FactoryNotFoundException: Factory not found: org.eclipse.net4j.connectors[tcp] like the Bugzilla_329786_Test in the test suite (which is not launched on hudson.eclipse) and I don't understand why, but the testcase is sufficiently clear (for me :)) to understand my usecase. And we can see that the EMFT Transaction opening is done on the InvalidationEvent event reception just after the remote changes integraton which can be a issue if we have a precommit listener which throws a RollbackException to revert all remote changes integration. Then we needs a event juste before the AbstractCDOView.invalidate() call in CDOViewImpl.doInvalidate().
Created attachment 218990 [details] Test case / prototype Changed to one file make collaboration easier and fixed a couple of misconceptions regarding the test framework integration.
Now that we have a single Java file to exchange you could try to explain again, what it's all about :P Why does the test fail and why shouldn't it and so on...
Oh, note that some of my changes to the test case require changes to the test framework that I'm committing in the context of this bug: commit 23cfe3d7309d3826003ade17cdefa8369fbe5c4f
Created attachment 219047 [details] Updated release of the JUnit Hi Eike, I have updated the test case, there are 2 tests : - one for EMF Transaction commit - one for EMF Transaction rollback There is 2 clients the main and the OtherClient, the main have a ResourceSetListenerImpl named LocalResourceUpdater whose job is to add a new Category to the local Company when a new Category has been added to the shared Company, it throws a RollbackException if the new added shared Category is named "ROLLBACK" to rollback the shared Category addition. This use case works fine when it is the main user which add the shared Category to the shared Company but not when it is the OtherClient user which add the shared Category and commit because the LocalResourceUpdater is not called. The tests failed because the remote notifications (CDODeltaNotifications) are not seen between CDOViewInvalidationEvent and the CDOViewAdaptersNotifiedEvent events, then not seen by the TransactionalEditingDomainImpl to call its precommitListeners or to do the rollback in case a precommitListener throws a RollbackException. I have also noticed that 2 InvalidationRunnable are executed on commit of OtherClient user, then the EMFTAwareInvalidation receives 2 CDOViewInvalidationEvent while only one commit with one change have occured.
Created attachment 219370 [details] Updated release of the JUnit Bis In fact intercepting a CDOViewInvalidationEvent to start a EMF Transaction and CDOViewAdaptersNotifiedEvent for commit it works when there is no cross references to remotelly detached CDOObject to clean (CDOTransactionImpl.removeCrossReferences()), a event fired at the beginning of the CDOViewImpl.doInvalidate() will be usefull in this case to integrate cross references cleaning in a EMF Transaction. Then https://bugs.eclipse.org/bugs/show_bug.cgi?id=363695 will become useless with that.
Created attachment 219371 [details] A sequence diagram showing the CDO EMF Transaction interaction
Created attachment 219372 [details] A sequence diagram showing the CDO / EMF Transaction integration issue on removeCrossReferences
(In reply to comment #23) > event fired at the beginning > of the CDOViewImpl.doInvalidate() will be usefull in this case I generally like events a lot because they provide the potential for many new integrations. Please go ahead and propose a patch. I'm happy to help with questions ;-)
Created attachment 219417 [details] JUnit test showing CDO EMF Transaction integration I have updated the JUnit test case to have 4 tests : - one for a invalidation integration in a EMF Transaction commit without cross references to clean - one for a invalidation integration in a EMF Transaction commit with cross references to clean - one for a invalidation integration in a EMF Transaction rollback without cross references to clean - one for a invalidation integration in a EMF Transaction rollback with cross references to clean. These tests use a patch adding 2 new CDOView events similar to the CDOTransactionStartedEvent and CDOTransactionFinishedEvent but for the invalidation step in passive updates : - CDOViewInvalidationStartedEvent fired at the beginning of the invalidation, before the cross references to clean, the conflict to resolve and the CDODeltaNotifications to send - CDOViewInvalidationFinishedEvent fired at the end of the invalidation just after the CDODeltaNotifications sending.
Created attachment 219419 [details] Patch adding 2 CDOViewEvents In attachment the patch adding the 2 CDOViewEvents. There are still issues with EMF Transaction rollback on remote changes integration (invalidation), indeed in our application a user could choose to undo (EMF Transaction rollback) the remote changes integration by throwing a RollbackException in the LocalResourceUpdate (as in the test case example). But during the EMF Transaction rollback I encounters the following exception with Bugzilla_323792_Test.testTransactionalEditingDomainRollback() : [ERROR] Object OID6 is invalid in branch 0 at * org.eclipse.emf.cdo.util.InvalidObjectException: Object OID6 is invalid in branch 0 at * at org.eclipse.emf.cdo.view.CDOInvalidationPolicy$1.handleInvalidObject(CDOInvalidationPolicy.java:38) at org.eclipse.emf.internal.cdo.view.CDOStateMachine$InvalidTransition.execute(CDOStateMachine.java:1144) at org.eclipse.emf.internal.cdo.view.CDOStateMachine$InvalidTransition.execute(CDOStateMachine.java:1) at org.eclipse.net4j.util.fsm.FiniteStateMachine.process(FiniteStateMachine.java:173) at org.eclipse.emf.internal.cdo.view.CDOStateMachine.read(CDOStateMachine.java:319) at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.getRevisionForReading(CDOStoreImpl.java:696) at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.getContainer(CDOStoreImpl.java:129) at org.eclipse.emf.internal.cdo.CDOObjectImpl.eInternalContainer(CDOObjectImpl.java:606) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseAdd(BasicEObjectImpl.java:1409) at org.eclipse.emf.ecore.util.DelegatingEcoreEList.inverseAdd(DelegatingEcoreEList.java:392) at org.eclipse.emf.common.notify.impl.DelegatingNotifyingListImpl.addUnique(DelegatingNotifyingListImpl.java:279) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:301) at org.eclipse.emf.common.util.ECollections.setEList(ECollections.java:185) at org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.process(FeatureChangeImpl.java:593) at org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(FeatureChangeImpl.java:518) at org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(FeatureChangeImpl.java:493) at org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.apply(ChangeDescriptionImpl.java:298) at org.eclipse.emf.transaction.util.CompositeChangeDescription.apply(CompositeChangeDescription.java:104) at org.eclipse.emf.transaction.impl.TransactionImpl.doRollback(TransactionImpl.java:570) at org.eclipse.emf.transaction.impl.TransactionImpl.commit(TransactionImpl.java:417) at org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_323792_Test$EMFTAwareInvalidation.commitEMFTTransaction(Bugzilla_323792_Test.java:436) at org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_323792_Test$EMFTAwareInvalidation.notifyEvent(Bugzilla_323792_Test.java:408) at org.eclipse.net4j.util.event.Notifier.fireEventSafe(Notifier.java:146) at org.eclipse.net4j.util.event.Notifier.fireEvent(Notifier.java:110) at org.eclipse.emf.internal.cdo.view.CDOViewImpl.fireInvalidationFinishedEvent(CDOViewImpl.java:942) at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:841) at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1578) at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26) at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1) at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:86) at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:77) at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
Have you tried with CDOInvalidationPolicy.RELAXED?
Created attachment 219614 [details] Updated JUnit tests Yets with CDOInvalidationPolicy.RELAXED and CDOStaleReferencePolicy.PROXY I haven't anymore exception. Thanks for you help. But the rollback on the 2 last tests doesn't restore some changes, the ContainmentObject1.containmentList:[ContainmentObject3] is not restored.
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
I think this bug should be re-focused at delivering ChangeRecorder(s) and EditingDomain(s) using lazy adapting for use with large models that are only partially loaded by CDO. In other words, change existing implementations from using EContentAdapter to using CDOLazyContentAdapter. Maybe it would be a good start to provide plain non-transactional implementations of lazy adapting "CDOChangeRecorder" and "CDOEditingDomain". Better still. Why not change existing ChangeRecorders and an EditingDomains to work with pluggable content adapters. That is, make them delegate to the adapter of your choice to perform the adaption. ///Anders
(In reply to comment #32) > I think this bug should be re-focused at delivering ChangeRecorder(s) and > EditingDomain(s) using lazy adapting for use with large models that are only > partially loaded by CDO. I have the feeling they're different issues and should be tracked differently. Martin would have to comment on this, as he submitted this bug. > In other words, change existing implementations from using EContentAdapter > to using CDOLazyContentAdapter. What exactly do you mean by "existing implementations"? > Maybe it would be a good start to provide plain non-transactional > implementations of lazy adapting "CDOChangeRecorder" and "CDOEditingDomain". > > Better still. Why not change existing ChangeRecorders You should cc Ed Merks and ask him why ChangeRecorder doesn't reuse EContentAdapter. To me he said that, for example, a ChangeRecorder must hold on to detached elements. > and an EditingDomains How are EditingDomains related to content adapters? > to work with pluggable content adapters. That is, make them delegate to the > adapter of your choice to perform the adaption. And that would probably also apply to all other occasions that involve content adaptation?
(In reply to comment #33) > (In reply to comment #32) > > I think this bug should be re-focused at delivering ChangeRecorder(s) and > > EditingDomain(s) using lazy adapting for use with large models that are only > > partially loaded by CDO. > > I have the feeling they're different issues and should be tracked > differently. > Martin would have to comment on this, as he submitted this bug. > > > In other words, change existing implementations from using EContentAdapter > > to using CDOLazyContentAdapter. > > What exactly do you mean by "existing implementations"? I was thinking mainly of ChangeRecorder and TransactionChangeRecorder. But the word "change" should be replaced with "create CDO versions of". > > > Maybe it would be a good start to provide plain non-transactional > > implementations of lazy adapting "CDOChangeRecorder" and "CDOEditingDomain". > > > > Better still. Why not change existing ChangeRecorders > > You should cc Ed Merks How? > and ask him why ChangeRecorder doesn't reuse > EContentAdapter. > To me he said that, for example, a ChangeRecorder must hold on to detached > elements. There is certainly tricky stuff going on in ChangeRecorder but the question is if this can be done orthogonal to the adaption mechanism, i.e. making the adapter pluggable. If so then the best way to provide support for a lazy adapting ChangeRecorder might be to "change" existing implementations as mentioned above, meaning changing the existing EMF ChangeRecorder and TransactionChangeRecorder. At least, a lazy adapting CDOChangeRecorder need to do all the stuff that ChangeRecorder does today only using CDOLazyContentAdapter instead of its present adapter implementation. > > > and an EditingDomains > > How are EditingDomains related to content adapters? I guess EditingDomains aren't related to adapters in their purest form. But they need change recorders and all implementations of EditingDomain I can find inherit from AdapterFactoryEditingDomain (but I fail to understand how it can be used exactly). > > > to work with pluggable content adapters. That is, make them delegate to the > > adapter of your choice to perform the adaption. > > And that would probably also apply to all other occasions that involve > content adaptation? Well, at least it would be nice if it could work that way.
> I was thinking mainly of ChangeRecorder and TransactionChangeRecorder. But > the word "change" should be replaced with "create CDO versions of". That's generally possible but someone would have to do the work ;-) > > You should cc Ed Merks > How? Just edit the CC List of this bug and add ed.merks@gmail.com But I'd suggest to open a new bugzilla. > > and ask him why ChangeRecorder doesn't reuse > > EContentAdapter. > > To me he said that, for example, a ChangeRecorder must hold on to detached > > elements. > There is certainly tricky stuff going on in ChangeRecorder but the question > is if this can be done orthogonal to the adaption mechanism, i.e. making the > adapter pluggable. If so then the best way to provide support for a lazy > adapting ChangeRecorder might be to "change" existing implementations as > mentioned above, meaning changing the existing EMF ChangeRecorder and > TransactionChangeRecorder. That's probably possible but outside the scope of CDO. Again, someone would have to do the work ;-) > At least, a lazy adapting CDOChangeRecorder need to do all the stuff that > ChangeRecorder does today only using CDOLazyContentAdapter instead of its > present adapter implementation. I haven't analyzed all aspects of ChangeRecorder in detail, so I hesitate to confirm this assertion. > > How are EditingDomains related to content adapters? > I guess EditingDomains aren't related to adapters in their purest form. But > they need change recorders and all implementations of EditingDomain I can > find inherit from AdapterFactoryEditingDomain (but I fail to understand how > it can be used exactly). That's a little vague.
Just adding Ed to the CC List will probably not make him read this entire 10 pages bug (which would be unnecesaary, too) ;-)
(In reply to comment #35) > > I was thinking mainly of ChangeRecorder and TransactionChangeRecorder. But > > the word "change" should be replaced with "create CDO versions of". > > That's generally possible but someone would have to do the work ;-) > > > > You should cc Ed Merks > > How? > > Just edit the CC List of this bug and add ed.merks@gmail.com > But I'd suggest to open a new bugzilla. > > > > and ask him why ChangeRecorder doesn't reuse > > > EContentAdapter. > > > To me he said that, for example, a ChangeRecorder must hold on to detached > > > elements. > > There is certainly tricky stuff going on in ChangeRecorder but the question > > is if this can be done orthogonal to the adaption mechanism, i.e. making the > > adapter pluggable. If so then the best way to provide support for a lazy > > adapting ChangeRecorder might be to "change" existing implementations as > > mentioned above, meaning changing the existing EMF ChangeRecorder and > > TransactionChangeRecorder. > > That's probably possible but outside the scope of CDO. > Again, someone would have to do the work ;-) 1. Yes, and that someone needs to understand ChangeRecorder well. 2. And its desirable to do it without duplicating code. 3. It would also be good if the resulting ChangeRecorder and/or TransactionChangeRecorder could be used together with existing editing domain implementations. Otherwise new implementations of EditingDomain have to be created as well. Therefore I think that factoring out the adapter from ChangeRecorder and/or TransactionChangeRecorder may be an efficient way to provide this functionality to CDO models. If at all possible. Ed, do you think it would be possible to make ChangeRecorder delegate adaptation to a pluggable adapter so that ChangeRecorder could be used with a CDOLazyContentAdapter? > > > At least, a lazy adapting CDOChangeRecorder need to do all the stuff that > > ChangeRecorder does today only using CDOLazyContentAdapter instead of its > > present adapter implementation. > > I haven't analyzed all aspects of ChangeRecorder in detail, > so I hesitate to confirm this assertion. > > > > How are EditingDomains related to content adapters? > > I guess EditingDomains aren't related to adapters in their purest form. But > > they need change recorders and all implementations of EditingDomain I can > > find inherit from AdapterFactoryEditingDomain (but I fail to understand how > > it can be used exactly). > > That's a little vague. For sure!
In an attempt to narrow down the scope I submitted this bug: "Provide a lazy adapting ChangeRecorder" https://bugs.eclipse.org/bugs/show_bug.cgi?id=388770 There may be an overlap.
Hi, To come back to the remote changes in EMFT Transaction solution, I have met a related bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=389173 , which block the use of this solution.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
