addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblinklocation-pinlockm-swarmSearchmailmessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] Maintaining a consistent view

From: Martijn V.
Sent on: Saturday, March 16, 2013 12:52 PM
In fact Richard and John solved this problem recently at jClarity, it was an interesting discussion, espeically around the time vs id ordering - as it turns out you just can't trust clocks :-).


On 15 March[masked]:47, Richard Warburton <[address removed]> wrote:

The problem is how to ensure that the UI maintains a consistent view
of the DB. By consistent, I mean that if no changes occur to the DB
for a sufficiently long period, the UI should eventually come to
reflect the current state of the DB.

This is termed "eventual consistency".  I mention the name because gify more easily applies if you know it!

If the UI receives "DB contains A, B, C" followed by "B removed" then
it will show a correct view of the DB; but if it receives "B removed"
followed by "DB contains A, B, C", it will incorrectly show that the
DB contains item B - and the view will remain incorrect indefinitely.

There's an obvious but heavy solution: poll the database for its
entire contents periodically. That achieves the goal of eventual
consistency, but I'm wondering whether there's a lighter solution -
this seems like a problem people must run into quite often.

I think the simplest way to address the problem that you mention is to define an ordering for your events - this might be a unique index for each event which gets updated, or it might be a timestamp.  Be wary of usual time related caveats with the timestamp based approach: ie different machines may be out of sync, and it may go backwards.  If you have properly synchronised time then don't worry - but that isn't usually the case.

A more sophisticated approach to order based conflict resolution, which you may also want to look at, is a vector clock [0].

As to whether this is a common problem - who's to say, no one does proper empirical research on what concurrency problems developers face.  All I can offer is the anecdote that its a problem I've encountered more than once.

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Richard Warburton ([address removed]) from LJC - London Java Community.
To learn more about Richard Warburton, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy