Fork me on GitHub

The documentation on sync has mentions a deprecated arity of db (and by extension open-db ) >

>   returned date is the latest transaction time indexed by this node. This can be
>   used as the second parameter in (db valid-time, transaction-time) for
>   consistent reads.


if I can piggyback on this: The reason I looked at sync was because I wondered about this: If I pass a node to multiple route handlers that may run concurrently, do they need to call sync first before calling db and using the return value as the basis? I assume yes. Or is this only necessary in specific contexts?


Calling sync first will definitely help to reduce the window for inconsistent reads across concurrent readers, but if you have a sufficiently high throughput of writes then it still may not give the consistency properties you're after. Do the concurrent readers communicate out of band? Is your app processing transactions off the back of the reads? In the extreme case you may want to use a transaction function to maximise consistency (such that everything happens serially)


> if I can piggyback on this always 🙂


Ah OK. No I'm only generally worried about getting an exception thrown in my face when I want to read from the db, while someone else writes. I don't mind waiting for indexing to finish. Plus the writes are always right in for the general case. Thank you for pointing out the right questions to ask though!

blob_thumbs_up 2