Community
Participate
Working Groups
Build Identifier: 20100917-0705 A. Use Case description In order to be able to use both CDO and a transactional framework (EMFTransaction for example), the passive update mode must be disabled. Indeed, if the passive update mode is activated, remote changes won't be integrated inside a Command of the EditingDomain commandStack, causing IllegalState Exceptions. On an other hand, we need to be notified of any remote changes in order to integrate them properly to the EditingDomain. This use case have already been discussed, please see http://www.eclipse.org/forums/index.php?t=msg&goto=559360&S=d2575181f9e963b075ed35f97229f38a#msg_559360. B. Work-Arounds In order to allow CDO to work with other transactional frameworks, we have identified two solutions : 1. Using two cdo sessions We first thought of a mechanism based on two sessions : - the first session has no passive update mode, and is used to commit changes - the second session has activated the passive update mode, and receive notifications whenever Repository content changes. When receiving such notifications, it will execute the refresh() method on the first session, inside a Command of the Editing Domain's Command Stack. No transaction is opened on this session, as it is just used to be notified of remote changes. Although this mechanism worked perfectly, it seemed a bit shaky and not efficient. 2. Integration of remote changes inside the transactional change recorder We then studied how to integrate remote changes directly inside the transactional Change Recorder (EMF transaction). If the Notification received by this Change Recorder is a Remote Notification (i.e coming from the Repository), we append the changes inside a Command. Otherwise, we append the notification as a standard transactional Change Recorder would do. The main problem is that it's hard to determine whether a notification is Remote or Local : for now on, we have considered that a Remote Notification is a Notification that is received when no local transaction is currently being executed. It's partly true, but Remote Notifications can also been received while a local modifications is currently executed inside a transaction. This solution, although more effecient, is far from being perfect and reliable. C. Feature Request It seems that the best and the most generic approach will be to allow users to deactivate passive update mode and yet be able to be notified of CDOSessionInvalidationEvents. A good solution might be to be able of activate/deactivate the passive update mode for a Transaction instead of a Session : by doing so, one can still attach Listeners to the Session (and consequently receive notifications for any remote change), but the elements won't be locally updated. Reproducible: Always
I'm still thinking about this one. Some comments so far: 1) A notification is a remote notification if it's an instanceof CDONotification. Maybe that's enough to exclude them from the change recorder's change description? 2) PassiveUpdates are really an aspect of a CDOSession, not of a CDOView. We had discussions about an additional property in the view options that controls whether incoming remote invalidation are directly processed by the view or stored in a queue for later processing. The detaiuls for this later processing are unclear, though. 3) A second session doesn't look like a very slim solution as it would involve a separate revision cache ;-(
Just a quick side note: I solved this issue on Dawn with overriding the TDE to gain control over the TransactionChangeRecorder (see DawnChangeRecorder). We already started discussing the implementation of an CDO internal TED in this bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=323792)
(In reply to comment #2) > ... CDO internal TED ... You certainly mean a CDO-specific TED ;-)
Certainly. ;)
Moving all open enhancement requests to 4.1
Guys, I think the title of this enhancement request is confusing. Is it about adding a CDO-specific TED? If so, can someone please update the title accordingly?
Hi, A little question, it is not better to have a IListener which listens CDOSessionInvalidationEvent to start a EMFT Transaction and listens CDOViewAdaptersNotifiedEvent to commit this EMFT Transaction or rollback it if a problem has occured during the invalidation. This solution could avoid to use a CDO specific TED, but a issue is that the CDOSessionInvalidationEvent is sent in a different thread than the CDOViewAdaptersNotifiedEvent.
Eike: no, this issue is not about adding a CDO-specific TED, it's just one of the possible solutions (see first message of this ticket).
> In order to be able to use both CDO and a transactional framework > (EMFTransaction for example), the passive update mode must be disabled. Let's see if I follow this assertion :P > Indeed, if the passive update mode is activated, remote changes won't be > integrated inside a Command of the EditingDomain commandStack, causing > IllegalState Exceptions. > On an other hand, we need to be notified of any remote changes in order to > integrate them properly to the EditingDomain. That sounds like a contradiction. > In order to allow CDO to work with other transactional frameworks, we have > identified two solutions : Two transactional layers on top of each other do sound more like a lot of trouble with not much benefit, eh? Undoubtedly a CDOTransaction is the superior choice among the two. Why would you want to add another layer? I would like to clarify this before we dive into possible technical solutions.
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
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.
