Home » Modeling » EMF » [CDO] Dispatch of CDO Notifications
|
| Re: [CDO] Dispatch of CDO Notifications [message #631624 is a reply to message #631611] |
Fri, 08 October 2010 08:33   |
|
Hi Markus,
Comments below...
Am 08.10.2010 10:05, schrieb Markus Barchfeld:
> Hello,
>
> We are still evaluating the migration of an existing application to CDO. The application makes heavy use of EMF notifications to refresh views. We found that the dispatch of CDO Notifications varies in some ways from the dispatch of "original" EMF Notifications. Unfortunately that breaks existing code
Even after reading the remainder of your post I'm not absolutely sure whether this breakage is caused by CDO behaving differently or by your application making wrong or too many assumptions.
> and it is quite hard for us to estimate the remaining work to migrate to CDO. Therefore I am wondering if it is possible and makes sense to dispatch CDO Notifications in a way that is closer to the original EMF dispatch.
What version of CDO are you using?
In 4.0 several changes to the notification mechanism have been applied, some of them being related with conflict handling. Many of these changes have been back-ported to 3.0 maintenance recently.
>
> Some differences are
>
> 1) All model changes of an invalidation event are applied first then the notifications are dispatched.
This does not differ from normal EMF, does it? Change notifications are generally delivered after the change has happened.
> Therefore the notification handler finds a different environment in the CDO case.
Can you elaborate with an example?
> While the oldValue is perfectly well reconstructed from CDO this still matters whenever the notification handler navigates away from the notifier.
Matters how? Maybe an example?
> 2) Some changes are accumulated, e.g. instead of two add notifications with one object there will be one add notification with two objects
Where/why does that create a problem?
> 3) Some notifications are missing, e.g. notifications to opposite references
I'd think that those are only missing if the opposite object is not loaded in that CDOView. Couldn't we argue that the notification is not needed if your application did not care for that object so far?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Looking at the code it seems that 1) could be fixed quite locally in CDOViewImpl and 3) in the CDONotificationBuilder. However, I can not estimate how close we can get to the dispatch of original EMF notifications. For example, is it possible to maintain the order of changes and notifications within one commit?
>
> Would other users of CDO also benefit from further aligning the dispatch?
>
> Thanks
> Markus
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Dispatch of CDO Notifications [message #631672 is a reply to message #631624] |
Fri, 08 October 2010 12:26 |
 Markus Barchfeld
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
Hi Eike,
Thanks for your fast response. I think it is better to turn to an
example now.
On 08.10.10 10:33, Eike Stepper wrote:
>> We are still evaluating the migration of an existing application to
>> CDO. The application makes heavy use of EMF notifications to refresh
>> views. We found that the dispatch of CDO Notifications varies in some
>> ways from the dispatch of "original" EMF Notifications. Unfortunately
>> that breaks existing code
> Even after reading the remainder of your post I'm not absolutely sure
> whether this breakage is caused by CDO behaving differently or by your
> application making wrong or too many assumptions.
The example below should clarify this.
>> and it is quite hard for us to estimate the remaining work to migrate
>> to CDO. Therefore I am wondering if it is possible and makes sense to
>> dispatch CDO Notifications in a way that is closer to the original EMF
>> dispatch.
> What version of CDO are you using?
3.0 maintenance from 30/09 - including the patch for cdoPrefetch.
> In 4.0 several changes to the notification mechanism have been applied,
> some of them being related with conflict handling. Many of these changes
> have been back-ported to 3.0 maintenance recently.
>> Some differences are
>>
>> 1) All model changes of an invalidation event are applied first then
>> the notifications are dispatched.
> This does not differ from normal EMF, does it? Change notifications are
> generally delivered after the change has happened.
>
>> Therefore the notification handler finds a different environment in
>> the CDO case.
> Can you elaborate with an example?
Sure, hope that clarifies it. The focus here was on "all". Assume two
modifications in one commit, with x and y being 0 before the commit:
a.x=5
a.y=6
tx.commit()
If there is a notification handler on a which prints a.x,a.y we will get
the following result with original EMF
5,0
5,6
and
5,6
5,6
with CDO notifications. Because *all* changes of the invalidation event
are processed before the first notification will be dispatched. Whereas
with EMF notifications the notification handler is called immediately
after *every single* value is changed. Therefore we get "5,0" in the EMF
case when x is set and y has not been set but "5,6" in the CDO case in
the same situation.
In this example this does not look like a problem. However, assume that
there are 50 changes or so in one transaction commit the first
notification will see the model in some kind of future state.
>> While the oldValue is perfectly well reconstructed from CDO this still
>> matters whenever the notification handler navigates away from the
>> notifier.
> Matters how? Maybe an example?
See example below.
>> 2) Some changes are accumulated, e.g. instead of two add notifications
>> with one object there will be one add notification with two objects
> Where/why does that create a problem?
That should not be a problem, except that the notification handler could
so rely on getting single additions because the program logic has
prevented multiple additions. But that may be a poor design of the
notification handler.
>
>> 3) Some notifications are missing, e.g. notifications to opposite
>> references
> I'd think that those are only missing if the opposite object is not
> loaded in that CDOView. Couldn't we argue that the notification is not
> needed if your application did not care for that object so far?
No, the notification is missing although the opposite object is loaded.
As an example I picked a part from our model. There are two types
involved: VisualElementType and VisualElement. There are two
bidirectional associations between them:
class VisualElementType {
val AbstractVisualElement[*]#visualElementType visualElements;
val AbstractVisualElement[*]#visualElementTypeIfHidden
hiddenVisualElements;
}
class VisualElement extends VisualWithBounds {
ref VisualElementType#visualElements visualElementType;
ref VisualElementType#hiddenVisualElements visualElementTypeIfHidden;
}
Here is some test code:
@Before
public void setUp() throws Exception {
tx1 = createSession();
tx1.createResource("defaultConfiguration");
tx1.commit();
tx2 = createSession();
isOriginal = true;
}
private EList<EObject> getRoot(CDOTransaction transaction) {
return transaction.getResource("defaultConfiguration").getContents();
}
public void testCDONotification2() throws Exception {
EList<EObject> root = getRoot(tx1);
VisualElementType elementType = ModelFactory.eINSTANCE
.createVisualElementType();
root.add(elementType);
VisualElement element = ModelFactory.eINSTANCE.createVisualElement();
elementType.getVisualElements().add(element);
tx1.commit();
// if isOriginal is true we will see the original EMF
// notifications otherwise CDO notifications
EList<EObject> contents2 = isOriginal ? getRoot(tx2) : root;
VisualElementType otherType = (VisualElementType) contents2.get(0);
otherType.eAdapters().add(new AdapterImplementation());
VisualElement otherElement = (VisualElement) otherType
.getVisualElements().get(0);
otherElement.eAdapters().add(new AdapterImplementation());
// move element from visual elements to hidden visual elements
elementType.getVisualElements().remove(element);
elementType.getHiddenVisualElements().add(element);
tx1.commit();
}
And the notification handler on otherElement and otherType looks like:
Object notifier = notification.getNotifier();
EReference ref = (EReference) notification.getFeature();
String featureName = ref == null ? "feature not set" : ref.getName();
String info = "eventtype=" + display(notification.getEventType())
+ ", feature=" + featureName;
if (notifier instanceof VisualElement) {
VisualElement element = (VisualElement) notification
.getNotifier();
System.out.println(info + ", type="
+ element.getVisualElementType() + ", typeifhidden="
+ element.getVisualElementTypeIfHidden());
} else {
System.out.println(info);
}
If I run the code with original EMF, I get the following result
eventtype=SET, feature=visualElementType, type=null, typeifhidden=null
eventtype=REMOVE, feature=visualElements
eventtype=SET, feature=visualElementTypeIfHidden, type=null,
typeifhidden=VisualElementType@OID4
eventtype=ADD, feature=hiddenVisualElements
However, with CDO (30/09) it looks different:
eventtype=ADD, feature=hiddenVisualElements
eventtype=REMOVE, feature=visualElements
eventtype=SET, feature=feature not set, type=null,
typeifhidden=VisualElementType@OID4
With the current HEAD of the 3.0 Maintenance Branch I get another order:
eventtype=REMOVE, feature=visualElements
eventtype=ADD, feature=hiddenVisualElements
eventtype=SET, feature=feature not set, type=null,
typeifhidden=VisualElementType@OID3
Now the order seems to be restored. However, the SET notifications for
the reverse reference are still different: the feature is not set and
the first call which sets the type to null is still missing.
This example breaks our code because we use the SET notification to
remove UI elements referring to the moved visualElement.
Are the good reasons to omit the SET notification or is this just a bug
which could be solved?
Thanks
Markus
|
|
|
| Re: [CDO] Dispatch of CDO Notifications [message #631678 is a reply to message #631672] |
Fri, 08 October 2010 12:53 |
|
Hi Markus,
For the "opposite" issue, is it possible that you file a bugzilla with a test case that can run in our test framework? There are lots of examples in org.eclipse.emf.cdo.tests.
Regarding the "one notification for each single feature delta and that in the original order" I'm rather reluctant to see that very desirable. If a client calls the sequence a.x=7; a.x=5 in a loop with 1000 iterations that would mean that we transfer 2000 useless feature deltas through the network in all directions. We have spent considerable effort to optimize the storage and transfer of change sets as much as possible. I would rather suggest that you use only the information from the notification and not the underlying notifier, as that is not thread-safe anyway.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 08.10.2010 14:26, schrieb Markus Barchfeld:
> Hi Eike,
>
> Thanks for your fast response. I think it is better to turn to an example now.
>
> On 08.10.10 10:33, Eike Stepper wrote:
>
>>> We are still evaluating the migration of an existing application to
>>> CDO. The application makes heavy use of EMF notifications to refresh
>>> views. We found that the dispatch of CDO Notifications varies in some
>>> ways from the dispatch of "original" EMF Notifications. Unfortunately
>>> that breaks existing code
>> Even after reading the remainder of your post I'm not absolutely sure
>> whether this breakage is caused by CDO behaving differently or by your
>> application making wrong or too many assumptions.
> The example below should clarify this.
>
>
>>> and it is quite hard for us to estimate the remaining work to migrate
>>> to CDO. Therefore I am wondering if it is possible and makes sense to
>>> dispatch CDO Notifications in a way that is closer to the original EMF
>>> dispatch.
>> What version of CDO are you using?
> 3.0 maintenance from 30/09 - including the patch for cdoPrefetch.
>
>> In 4.0 several changes to the notification mechanism have been applied,
>> some of them being related with conflict handling. Many of these changes
>> have been back-ported to 3.0 maintenance recently.
>
>>> Some differences are
>>>
>>> 1) All model changes of an invalidation event are applied first then
>>> the notifications are dispatched.
>> This does not differ from normal EMF, does it? Change notifications are
>> generally delivered after the change has happened.
>>
>>> Therefore the notification handler finds a different environment in
>>> the CDO case.
>> Can you elaborate with an example?
> Sure, hope that clarifies it. The focus here was on "all". Assume two modifications in one commit, with x and y being 0 before the commit:
> a.x=5
> a.y=6
> tx.commit()
>
> If there is a notification handler on a which prints a.x,a.y we will get the following result with original EMF
>
> 5,0
> 5,6
>
> and
>
> 5,6
> 5,6
>
> with CDO notifications. Because *all* changes of the invalidation event are processed before the first notification will be dispatched. Whereas with EMF notifications the notification handler is called immediately after *every single* value is changed. Therefore we get "5,0" in the EMF case when x is set and y has not been set but "5,6" in the CDO case in the same situation.
>
> In this example this does not look like a problem. However, assume that there are 50 changes or so in one transaction commit the first notification will see the model in some kind of future state.
>
>>> While the oldValue is perfectly well reconstructed from CDO this still
>>> matters whenever the notification handler navigates away from the
>>> notifier.
>> Matters how? Maybe an example?
> See example below.
>
>
>>> 2) Some changes are accumulated, e.g. instead of two add notifications
>>> with one object there will be one add notification with two objects
>> Where/why does that create a problem?
> That should not be a problem, except that the notification handler could so rely on getting single additions because the program logic has prevented multiple additions. But that may be a poor design of the notification handler.
>>
>>> 3) Some notifications are missing, e.g. notifications to opposite
>>> references
>> I'd think that those are only missing if the opposite object is not
>> loaded in that CDOView. Couldn't we argue that the notification is not
>> needed if your application did not care for that object so far?
> No, the notification is missing although the opposite object is loaded.
>
> As an example I picked a part from our model. There are two types involved: VisualElementType and VisualElement. There are two bidirectional associations between them:
>
> class VisualElementType {
> val AbstractVisualElement[*]#visualElementType visualElements;
> val AbstractVisualElement[*]#visualElementTypeIfHidden hiddenVisualElements;
>
> }
>
> class VisualElement extends VisualWithBounds {
> ref VisualElementType#visualElements visualElementType;
> ref VisualElementType#hiddenVisualElements visualElementTypeIfHidden;
> }
>
> Here is some test code:
>
> @Before
> public void setUp() throws Exception {
> tx1 = createSession();
> tx1.createResource("defaultConfiguration");
> tx1.commit();
> tx2 = createSession();
> isOriginal = true;
> }
>
> private EList<EObject> getRoot(CDOTransaction transaction) {
> return transaction.getResource("defaultConfiguration").getContents();
> }
>
>
> public void testCDONotification2() throws Exception {
> EList<EObject> root = getRoot(tx1);
>
> VisualElementType elementType = ModelFactory.eINSTANCE
> .createVisualElementType();
> root.add(elementType);
> VisualElement element = ModelFactory.eINSTANCE.createVisualElement();
> elementType.getVisualElements().add(element);
> tx1.commit();
>
> // if isOriginal is true we will see the original EMF
> // notifications otherwise CDO notifications
> EList<EObject> contents2 = isOriginal ? getRoot(tx2) : root;
> VisualElementType otherType = (VisualElementType) contents2.get(0);
> otherType.eAdapters().add(new AdapterImplementation());
> VisualElement otherElement = (VisualElement) otherType
> .getVisualElements().get(0);
> otherElement.eAdapters().add(new AdapterImplementation());
>
> // move element from visual elements to hidden visual elements
> elementType.getVisualElements().remove(element);
> elementType.getHiddenVisualElements().add(element);
> tx1.commit();
> }
>
>
> And the notification handler on otherElement and otherType looks like:
>
> Object notifier = notification.getNotifier();
> EReference ref = (EReference) notification.getFeature();
> String featureName = ref == null ? "feature not set" : ref.getName();
> String info = "eventtype=" + display(notification.getEventType())
> + ", feature=" + featureName;
> if (notifier instanceof VisualElement) {
> VisualElement element = (VisualElement) notification
> .getNotifier();
> System.out.println(info + ", type="
> + element.getVisualElementType() + ", typeifhidden="
> + element.getVisualElementTypeIfHidden());
> } else {
> System.out.println(info);
> }
>
> If I run the code with original EMF, I get the following result
>
> eventtype=SET, feature=visualElementType, type=null, typeifhidden=null
> eventtype=REMOVE, feature=visualElements
> eventtype=SET, feature=visualElementTypeIfHidden, type=null, typeifhidden=VisualElementType@OID4
> eventtype=ADD, feature=hiddenVisualElements
>
>
> However, with CDO (30/09) it looks different:
>
> eventtype=ADD, feature=hiddenVisualElements
> eventtype=REMOVE, feature=visualElements
> eventtype=SET, feature=feature not set, type=null, typeifhidden=VisualElementType@OID4
>
> With the current HEAD of the 3.0 Maintenance Branch I get another order:
>
> eventtype=REMOVE, feature=visualElements
> eventtype=ADD, feature=hiddenVisualElements
> eventtype=SET, feature=feature not set, type=null, typeifhidden=VisualElementType@OID3
>
> Now the order seems to be restored. However, the SET notifications for the reverse reference are still different: the feature is not set and the first call which sets the type to null is still missing.
>
> This example breaks our code because we use the SET notification to remove UI elements referring to the moved visualElement.
>
> Are the good reasons to omit the SET notification or is this just a bug which could be solved?
>
>
> Thanks
> Markus
>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 19:38:50 GMT 2024
Powered by FUDForum. Page generated in 0.03119 seconds |
] 
Search
Help
Register
Login
Home
