[aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection

[Lukáš Fryč]

Oh, sorry for two answers, I noticed Dan already answered to some concerns
already. :-)

On Mon, Sep 8, 2014 at 12:33 PM, Lukáš Fryč <lukas.fryc at gmail.com> wrote:

>
>
> On Fri, Sep 5, 2014 at 8:32 PM, Randall Hauch <rhauch at redhat.com> wrote:
>>
>>
>> It’s also likely that for batch operations to work well for many
>> different kinds of applications, the server may support multiple policies
>> that specify for a given batch operation the atomicity, consistency, and
>> isolation guarantees. One policy might ensure that the entire batch either
>> completely succeeds only when there are no revision conflicts, otherwise it
>> completely fails. Another policy might be eventually-consistent in the
>> sense that the changes in every batch operations will eventually be
>> applied, though this may require the server to have application-specific
>> conflict resolution logic. And there are policies that are somewhere
>> in-between. For example, imagine a server that supports “public”
>> collections whose entities can be read/updated by any user, and “private”
>> collections that expose only the entities that are readable and editable by
>> that user. The likelihood of a concurrent update conflict on a private
>> entity is quite small, since it’s possible only when different changes made
>> on different devices are submitted at exactly the same time. On the other
>> hand, the likelihood of a concurrent update conflict on a public entity is
>> much higher. The server may allow updates to both public and private
>> entities within a single batch operation, and a save policy that might
>> update all private entities atomically (they all succeed or they all fail)
>> while updates to *each* public entity is atomic (some might succeed while
>> others might fail).
>>
>
>
> I don't believe LiveOak ensure ACID guarantees (at least not on batch
> update level; correct me if I'm wrong), and I don't think we should start
> with that.
> Any given REST call that leads to updating more than one endpoint is not
> atomic anymore.
>
> I would rather say that whole Data Sync is eventually consistent solution
> (at least in its first versions).
>
> Sure, app/user will know that there is a conflict on one of the updated
> entities (and we may provide an API to make the resolution easier), but it
> will be up to him to resolve it.
>
> Or am I wrong?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/71f963ab/attachment.html