I’m using on-prem and the dev storage protocol running locally for development, with the client api.
I’m rewriting a traditional (no-js) web application to use Datomic and Ring. I’m using a POST request which issues a transaction to update (“accumulate”) a datomic entity, which then immediately redirects to a GET route. That route then immediately issues a query for the data that’s just been written. (shared nothing pattern).
Very frequently the query in the GET request does not reflect the data which was written immediately previously. If I hit reload on the page again I see the changed state. I’ve printed to console at various points and am sure this is happening, browser cache is off etc.
I was under the impression that if I issue d/transact then when that command completes I can be confident that the database has “got it”. i.e., On the very next line of code, I can get a new database value and query against it and this value will reflect what I just transacted on the line before.
Is my assumption correct? Is this something to do with the dev storage protocol? The proportion of times I get the stale data has risen a lot when I try it again this morning, perhaps my jvms are a lot more sleepy at 8am Sunday morning…
Thinking about the architecture of datomic with the tx data having to reach the peer-server instantly, I can see there’s more going on here than in a system where reads & writes go through the same point.
Question though, how can I ensure I get fresh data ?!