|
| Re: [CDO] recommendations for handling conflicts between multiple cdo-server clients [message #517354 is a reply to message #517261] |
Sat, 27 February 2010 04:44   |
|
Hi Mark,
I think a conflict mitigation strategy comprises three things:
1) Reduce the potential for conflicts. If possible, try to add more
containers.
2) Resolve conflicts locally with a CDOConflictResolver. Maybe you're
interested in developing a subclass of ThreeWayMerge that resolves
certain feature-level like conflicting additions to many-valued
features? Such a mechanism could be of common interest. Let me know if
you need more infos.
3) Due to race conditions there will always be a rest potential for
conflicts that are only recognized by the repository when processing
commits. You will always have to expect these exceptions on the client
side. Ideally you'd rollback the transaction, re-apply your changes and
commit again.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 26.02.2010 18:39, schrieb Mark Geib:
> In a model designed to store real-time data what is the best way to
> handle conflicts where a container object has new children being added
> by multiple repository clients. We have many remote sources of real-time
> data "pumping" data to clients via a messaging framework that result in
> updates to the emf model for display by other GUI clients. However, due
> the large amount of the data we have multiple clients processing the
> messages and updating the model. There are cases where a message
> contains data for a new model object that is created and added to its
> container. This container is "shared" by all the message processing
> clients. Since we batch the model updates and only do save every N
> updates we will often have a save fail due to the fact the container
> object has been updated by another client so the version of our
> container is not valid.
>
> We are not sure how to best handle the exception. Do we somehow update
> the container, then replay all the commands since the last successful
> save. Or destroy the CDO transaction and create a new one completely.?
>
> Thanks for ANY suggestions,
> Mark
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] recommendations for handling conflicts between multiple cdo-server clients [message #517643 is a reply to message #517354] |
Mon, 01 March 2010 15:18 |
 Mark Geib
Messages: 432
Registered: July 2009 |
Senior Member |
|
|
Eike,
Thanks for the reply.
I am very interested in hearing more about the CDOConflictResolver.
Mark.
On 02/26/2010 09:44 PM, Eike Stepper wrote:
> Hi Mark,
>
> I think a conflict mitigation strategy comprises three things:
>
> 1) Reduce the potential for conflicts. If possible, try to add more
> containers.
>
> 2) Resolve conflicts locally with a CDOConflictResolver. Maybe you're
> interested in developing a subclass of ThreeWayMerge that resolves
> certain feature-level like conflicting additions to many-valued
> features? Such a mechanism could be of common interest. Let me know if
> you need more infos.
>
> 3) Due to race conditions there will always be a rest potential for
> conflicts that are only recognized by the repository when processing
> commits. You will always have to expect these exceptions on the client
> side. Ideally you'd rollback the transaction, re-apply your changes and
> commit again.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
> Am 26.02.2010 18:39, schrieb Mark Geib:
>> In a model designed to store real-time data what is the best way to
>> handle conflicts where a container object has new children being added
>> by multiple repository clients. We have many remote sources of real-time
>> data "pumping" data to clients via a messaging framework that result in
>> updates to the emf model for display by other GUI clients. However, due
>> the large amount of the data we have multiple clients processing the
>> messages and updating the model. There are cases where a message
>> contains data for a new model object that is created and added to its
>> container. This container is "shared" by all the message processing
>> clients. Since we batch the model updates and only do save every N
>> updates we will often have a save fail due to the fact the container
>> object has been updated by another client so the version of our
>> container is not valid.
>>
>> We are not sure how to best handle the exception. Do we somehow update
>> the container, then replay all the commands since the last successful
>> save. Or destroy the CDO transaction and create a new one completely.?
>>
>> Thanks for ANY suggestions,
>> Mark
>>
|
|
|
Powered by
FUDForum. Page generated in 0.03863 seconds
] 
Search
Help
Register
Login
Home
