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

Re: [ljc] Maintaining a consistent view

From: Michael R.
Sent on: Saturday, March 16, 2013 8:20 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks to everyone who responded! Taking the responses one at a time:

Wesley: I'm relieved to say this isn't a distributed system - the UI
and database are running in the same JVM, so there are no dropped
messages. Thanks for the suggestion of using timestamps and only
returning records that have changed - that could save a lot of
resources. Keeping it as simple as possible is also great advice.
However, I still think it must be possible to do better than periodic
polling.

Colin: Querying the DB in response to events would perform better than
polling, but it wouldn't solve the concurrency issue. It would still
be possible for the following to happen:

* Item A is updated, an event is fired, and the UI issues query X
* Query X reads the state of item A from the database
* Item A is updated again, an event is fired, and the UI issues query Y
* Query Y reads the state of item A from the database
* Query Y posts its results to the UI's message queue
* Query X posts its results to the UI's message queue

In that case the UI would end up with an out-of-date view of the state
of A.

It seems to me that there are two problems here. The first is a lack
of atomicity: queries X and Y are interleaved. That could be solved by
using a semaphore or similar to serialise the UI's queries. The second
problem is trickier: the UI may not receive events in the order
they're fired, as multiple worker threads may fire events, and a
thread may be scheduled out between an event being fired and the event
being handled.

Richard: I had considered defining an ordering by adding a version
number (perhaps implemented as an AtomicInteger) that would be
incremented with each state change. However, all database writes would
then have to serialise (albeit briefly) on the version number, whereas
the database currently permits parallel writes as long as they update
different tables. (I could create one version number per table, but
that would expose the database's internal structure to callers.)

Having said that, the performance hit of serialising briefly on the
version number might be a small price to pay for a simple and robust
solution to the problem!

James: Thanks for the pointer to the Disruptor. In my current project
the UI's message queue is implemented by the platform (Android), so
I'm not at liberty to change it, but I'll bear the Disruptor in mind
for  future projects.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRRNQB­AAoJEBEET9GfxSfMIT4H­/2Vt24FlBXlg6bHs72CM­ThrV
+5XMt/RIzoaTqWton94L­033K3ht2BzA9VzHXZ8ue­8NnOLn5KA1vjkzJbGLwB­8KNG
CrOoGQmc/NNBK7v27JNW­EdUGP3GdUykE6L1Vb2z4­P25OOFXLdaVdccm5r858­glxR
8yMDqwRaKeRRXYNpe5p/­HFxPrp56qdAhmlRzvLey­qIMnVjdn+5mgErlSU8r7­hJU8
APR2bssXIQdBO8uiY4H/­gGMz0kU0icB+y9n3xN6y­p4NWhacGDMnEE/K1AGO1­VHnN
cMMeT6X/3OoCsqvVWllU­wLrQKo1C8b32sPWcntbC­emo05ncdf7WlEq7FEEbl­7FA=
=QHES
-----END PGP SIGNATURE-----

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

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