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: Ged B.
Sent on: Saturday, March 16, 2013 8:43 AM
Hi Michael,

Have you considered using Merkle Trees?  


A merkle is a hierarchy of hashes used to achieve eventual consistancy in most NoSQL solutions and the Google Wave protocol.

Inline images 1

For example, you may have a hash for every row in the table.  This is generated based on the table contents, rather like the hash method of a java bean.

Then you have a hash for the table, or a portion of the table.  This is based on the hashes for the rows it covers.

Every time you update a row, you update the hash.  You then update any hashes that depend upon that hash.  You work your way up the tree to the root.

To poll the entire database you only have to poll the database hash.  When the hash changes you drill down to discover the update tables then the updated rows.  You can make the hierarchy more sophisticated to achieve something more efficient.  You can have a hierarchy that reflects your entity or view composition rather than the database structure.

You might want to maintain the hash in the database, using triggers.  If you're using JPA you might want to hold it in the session.  After all, your beans already have hashes.  If all updates go through a single session you can maintain your trees there using JPA interceptors.

You might also want to consider B-Trees.  CouchDB switched to B-Tree because there were simpler and more memory efficient: http://guide.couchdb.org/draft/btree.html

I hope you find this helpful.

Regards, 


Ged


On 15 March[masked]:51, Michael Rogers <[address removed]> wrote:

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.

Any advice?

Cheers,
Michael
-

This email message originally included an attachment.

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