Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 329777

Summary:	No passive update mode and ChangeSubscriptionPolicies (compatibility with other transactional frameworks)
Product:	[Modeling] EMF	Reporter:	Alex Lagarde <alex.lagarde>
Component:	cdo.core	Assignee:	Project Inbox <emf.cdo-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	esteban.dugueperoux, lu.xingxiao, martin.fluegge, stepper, vroldanbet
Version:	4.13
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Alex Lagarde

2010-11-09 08:09:29 EST

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

Comment 1 Eike Stepper

2010-11-13 04:09:47 EST

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 ;-(

Comment 2 Martin Fluegge

2010-11-13 04:50:58 EST

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)

Comment 3 Eike Stepper

2010-11-13 05:45:14 EST

(In reply to comment #2)
> ... CDO internal TED ...

You certainly mean a CDO-specific TED ;-)

Comment 4 Martin Fluegge

2010-11-13 06:41:49 EST

Certainly. ;)

Comment 5 Eike Stepper

2011-06-23 03:59:17 EDT

Moving all open enhancement requests to 4.1

Comment 6 Eike Stepper

2012-04-04 10:21:02 EDT

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?

Comment 7 Esteban DUGUEPEROUX

2012-04-05 04:39:03 EDT

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.

Comment 8 Alex Lagarde

2012-04-05 04:41:50 EDT

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).

Comment 9 Eike Stepper

2012-04-05 05:26:17 EDT

> 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.

Comment 10 Eike Stepper

2012-08-14 22:54:01 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 11 Eike Stepper

2013-06-27 04:09:10 EDT

Moving all outstanding enhancements to 4.3

Comment 12 Eike Stepper

2014-08-19 09:28:55 EDT

Moving all open enhancement requests to 4.4

Comment 13 Eike Stepper

2014-08-19 09:37:56 EDT

Moving all open enhancement requests to 4.4

Comment 14 Eike Stepper

2015-07-14 02:16:03 EDT

Moving all open bugzillas to 4.5.

Comment 15 Eike Stepper

2016-07-31 00:59:01 EDT

Moving all unaddressed bugzillas to 4.6.

Comment 16 Eike Stepper

2017-12-28 01:17:01 EST

Moving all open bugs to 4.7

Comment 17 Eike Stepper

2019-11-08 02:15:41 EST

Moving all unresolved issues to version 4.8-

Comment 18 Eike Stepper

2019-12-13 12:47:55 EST

Moving all unresolved issues to version 4.9

Comment 19 Eike Stepper

2020-12-11 10:39:48 EST

Moving to 4.13.