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

[Lukáš Fryč]

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/eb0f6c9c/attachment.html