Closed ericnormand closed 9 years ago
Why was this closed?
I merged it together with the related branch with the transaction functions.
On Thu, Sep 10, 2015 at 8:38 AM, Christopher Shea notifications@github.com wrote:
Why was this closed?
— Reply to this email directly or view it on GitHub https://github.com/democracyworks/datomic-toolbox/pull/11#issuecomment-139236759 .
Add a function + macro for doing retries when a ConcurrentModificationException happens in datomic.
This function allows us to make atomic updates to a database. Currently, we have many non-atomic updates to the database. You can identify a non-atomic update because it:
If anything has modified the database between t0 and tn, this transaction data may be stale, yet still be recorded. For instance:
page-view
. It reads the currentpage-view
count at t0, which is 100.page-view
. It reads the currentpage-view
count at t0, which is 100.(inc page-view)
at t1. Datomic storespage-view
= 101.(inc page-view)
at t2. In its memory,page-view
is still 100. Datomic storespage-view
= 101.After two increments,
page-view
should be 102, but it's 101. This function, along with the database functions defined in #8, will help us make sure everything is counted.Using this new function and the
:transact
database function, the corrected situation above will look like:page-view
. It reads the currentpage-view
count at t0, which is 100.page-view
. It reads the currentpage-view
count at t0, which is 100.[:transact userid :page-view 100 101]
at t1. That means "storepage-view
=101 given that it is equal to 100". Datomic storespage-view
= 101.[:transact userid :page-view 100 101]
at t2. This fails with a ConcurrentModificationException.page-view
count at t3, which is 101.[:transact userid :page-view 101 102]
at t4. Datomic storespage-view
= 102.Two increments, and
page-view
is 102, which is correct!There is an example in
election-notification-works
.