Bugzilla – Full Text Bug Listing
| Summary: | CDOLegacyAdapter modifies Store even for Touch notifications | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Alex Lagarde <alex.lagarde> | ||||||
| Component: | cdo.legacy | Assignee: | Eike Stepper <stepper> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | esteban.dugueperoux, martin.fluegge, stepper | ||||||
| Version: | 4.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 492898 | ||||||||
| Attachments: |
|
||||||||
|
Description
Alex Lagarde
Created attachment 183517 [details]
Test v1
This is not a Legacy but a CDO related problem/feature. In this case legacy behaves exactly as native would do (see attached test).
If we would change this in legacy we would behave different to native models. We could handle TouchNotification more carefully, but this must be done in the core itself.
Eike, what do you think?
I *think* this is a duplicate of bug 312534. Alex, please reopen if you disagree. *** This bug has been marked as a duplicate of bug 312534 *** Eike, the bug 312534 doesn't describe exactly the same issue : it's about the CDO State machine and how this state machine should put CDOOObjects in CLEAN State if modifications are reverted. Although I agree it is an interesting feature, I see this as an improvement of CDO. The issue described here is more a bug to me, as it's about unrelevant calls to the store, which can lead to unnecessary conflicts : imagine that 2 CDO Clients load the same CDOObject "A" (let's say it's an Object that references all CDOObjects having some special property). The 2 client applications always modify A by refreshing those references(every 5 seconds for instance). Even if the referenced objects don't change, CDO will be notified of any SET operation that will be made. Although the notification indicates it's a Touch modification, the modification will be impacted on the store (for both clients), causing : - unnecessary revision increase (which will lead to unnecessary conflicts when clients will commit) - bad performance (imagine that this Object references 10 000 elements, these will always be changed in the store every 5 seconds) I don't know if I made myself clear, let me know if you agree with me ! If you correct the bug 312534, the revision number issue will be corrected but you will still have a lack of performance. See previous comment Created attachment 185024 [details]
Fix v1
Alex, I seemd to be confused by the ambiguity of the word "store" but I start to understand that you mean the CDOStore and not an IStore. Are you asking for something like the condition in fix v1?
Eike, this is exactly what I had in mind. Ensuring that the CDOObject has effectively changed before calling store.set will avoid unnecessary revision increasing. Added skipUnlessConfig(LEGACY) to the test. To make it pass in NATIVE mode we'd probably need to fix bug 312534. Committed to HEAD I am not sure whether it is a good decision to change the CDOLegacyAdapter in a way that it behaves differently form the NATIVE mode regarding core behavior like changes in the store. Since bug 312534 is rather old an I am not sure that it is related to this bug, shouldn't we raise an additional bug for the TouchNotification handling for Native? Both bugs ask for not incrementing the version if no change occured. I don't see a value in delaying the simple fix for LEGACY until the complicated fix for NATIVE is in place. Available in R20110608-1407 |