|
|
|
| Re: [EMFStore]Matching elements by attribute value [message #1661320 is a reply to message #1637371] |
Mon, 09 March 2015 15:25   |
 Aboubacar Kaba
Messages: 9
Registered: March 2015 |
Junior Member |
|
|
Hi Maximilian,
I'm working with Alain who first asked the question about the ability to guarantee uniqueness of entry. I implemented the ReservationSetModifier like you suggested. It seems working (until the contrary). However, I want to share with you the behavior we are seeing in order to tell us whether it is "normal" behavior or not.
ClientA and ClientB add same child element (for us same name) to a given container, and ClientB first commits.
When ClientA updates, conflict is detected.
If ClientA chooses to "Keep All Their Changes", it ends up with two local changes: creation of the child and deletion of that child. And it will have to commit them (going to a new version number) or to revert them in order to be in sync. If ClientA choose to commit and ClientB updates later on, they are in sync with no problem (meaning "no duplicate" rule is meet).
But if ClientA chooses to "Keep All My Changes", it ends up with more operations to commit: basically all operations involved to create and set the name of the child element plus the deletion of the incoming child element. And it has to commit these operations. When ClientB updates later on, it will be in sync with no problem (no duplicate child).
Note that I called ReservationSetModifier.addFullReservation(parentId) to add a reservation to the container where parentId is its ID.
What do you thing of this?
Cheers,
|
|
|
| Re: [EMFStore]Matching elements by attribute value [message #1682024 is a reply to message #1661320] |
Tue, 17 March 2015 15:05 |
Maximilian Koegel
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Hi,
sorry for the delayed reply, I was at EclipseCon NA last week.
From you description it is hard for me to say which operations to expect
exactly, however it is generally normal that the operations will differ
for rejecting local (=accepting remote) and rejecting remote (accepting
local) changes.
Is there any specific problem with that or was this just a question to
make sure this is not odd behavior?
Cheers,
Maximilian
Am 09.03.2015 um 16:42 schrieb Aboubacar Kaba:
> Hi Maximilian,
>
> I'm working with Alain who first asked the question about the ability to
> guarantee uniqueness of entry. I implemented the ReservationSetModifier
> like you suggested. It seems working (until the contrary). However, I
> want to share with you the behavior we are seeing in order to tell us
> whether it is "normal" behavior or not.
>
> ClientA and ClientB add same child element (for us same name) to a given
> container, and ClientB first commits.
>
> When ClientA updates, conflict is detected.
> If ClientA chooses to "Keep All Their Changes", it ends up with two
> local changes: creation of the child and deletion of that child. And it
> will have to commit them (going to a new version number) or to revert
> them in order to be in sync. If ClientA choose to commit and ClientB
> updates later on, they are in sync with no problem (meaning "no
> duplicate" rule is meet).
>
> But if ClientA chooses to "Keep All My Changes", it ends up with more
> operations to commit: basically all operations involved to create and
> set the name of the child element plus the deletion of the incoming
> child element. And it has to commit these operations. When ClientB
> updates later on, it will be in sync with no problem (no duplicate child).
>
> Note that I called ReservationSetModifier.addFullReservation(parentId)
> to add a reservation to the container where parentId is its ID.
>
> What do you thing of this?
>
> Cheers,
>
>
--
Maximilian Kögel
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02160 seconds
Search
Help
Register
Login
Home
