Does Datomic ship all transactions to all connected peers on "commit"? -

the datomic transactor pushes live changes connected peers maintain live index.

does mean all data gets transacted sent peers connected - interested in data or not? or e.g. recent db transaction id?

the empirically reached answer: yes, full contents of transactions (and more *) gets streamed connected peers.

i confirmed connecting peer a transactor , let either

1. just sit there, staying connected or
2. monitor transactions means of tx-report-queue or
3. monitor transactions , print attribute values of entities modified in transaction

concurrent each of above test runs, peer b execute 4 transactions, each transaction change couple of simple properties of single entity, 1 of attributes being 5k random string data, other attributes short strings.

wireshark captured tcp connection between peer , transactor, , total byte size of tcp dumps can seen in following table.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━   case  tx-report-queue  print  bytes (5kb)  bytes (13kb)  ──────────────────────────────────────────────────────────      1                                61348        127996       2  ✓                             61800        128084       3  ✓                ✓            61260        127652  ──────────────────────────────────────────────────────────  no-tx                                13076         12988  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

the relative dump sizes differ less 500 bytes, far less single of 4 committed transactions, change more 5kb each, incur.

i ran test without doing transactions, , tcp dump shrink 13kb. therefore take it transaction data being transmitted.

*) back-of-the-envelope: the per transaction cost of transactor<->peera data (61kb-13kb)/4tx = 12kb/tx. looks when changing property, both retraction (5kb 1 string) , addition (again 5kb) transmitted via transactor's live index, give 10kb, plus little spare room of 2kb other (much smaller) modified attributes, (plus more heart beats, occur every 5 seconds , add 300 bytes, in test cases transactions performed, because of time took run tests).

edit put inferences on more solid foundation, reran tests 13kb string instead of original 5k. results (added table) seem confirm theory: per-transaction cost (128kb-13kb)/4tx = 29kb/tx, 13kb retraction + 13kb addition + 3kb slack.

---

further edit ran more tests, graphing bytes received respective peera*s. both traffic transactor, done via single tcp connection, , traffic datomic:free:// (i.e. h2) storage, in cases involved 3 tcp connections same h2 port.

i ignored tcp traffic in direction of transactor , storage, less.

• peera1 starts empty database
  1. monitors transactions via [tx-report-queue]
  2. prints attribute values of entities modified in every transaction
  3. queries elements in database every 4 seconds
• peerb performs above 13kb string attribute change , few other small attribute changes every 6 seconds
• peera2 starts populated database , peerb still running
  1. monitors transactions via [tx-report-queue]
  2. prints attribute values of entities modified in every transaction
• peera3 starts populated database , peerb still running
  1. monitors transactions via [tx-report-queue]
• peera4 starts populated database , peerb still running
  1. does nothing besides connecting datomic , waiting

and here's chart of rx traffic (of peera*s):

how read chart:

• the transactor pushes tx data on commit, whether peera interested in or not
• the transaction data contains, in addition data "additions", implicit retractions (that's why first transactor spike after starting peerb half size of later spikes - first time there no data yet, hence nothing retract)
• storage used read (from log in storage - not index - data in database less memory-index-threshold=32m, i.e. indexing not kick in during test)
• storage not used when peera1 queries database; in fact, queries not incur noticable network traffic
• storage read size when starting peers grows db accretes data (regardless of fact data "overwritten" -> datomic history)