Could someone explain or send a link to documentation on xtdb ’s consistency behavior for transactions? Mainly, I’m curious if xtdb supports ACID guarantees when performing read/write transactions against “arbitrary” data stored inside xtdb (vs a client can only use 1 CAS per transaction)
2 Likes
XT uses a single-threaded writer model without interactive transactions, so has a ‘serializable’ consistency level.
(from Slack)
what do you mean by interactive transactions? I wonder if we are talking about the same thing. For example, in an rdbms you can open a transaction, do multiple read and write queries and can expect ACID compliance. Does XTDB support transactions with multiple read and write queries?
I think we’re talking about the same thing, yes. In XT, (write) transactions are separated from reads - write transactions are sent, as a single unit, asynchronously, to the transaction log (likely Kafka). These transactions are then executed in a single thread - this means every transaction has a ‘serializable’ isolation level. If you want to do reads as well as writes in a transaction, these can be sent as a ‘transaction function’. They’re not interactive in the same way RDBMS transactions can be interactive, but they serve a lot of the use cases, albeit with any ‘interactive’ decision-making done on the single-threaded writer rather than on the client.
Read-only ‘transactions’ are entirely separate from the transaction processing. These take a consistent snapshot of the database at a point in time, and you can run multiple read-only queries, interactively, on the client, against a single snapshot.
Hope that roughly answer your questions? If not, do let us know 
James
3 Likes
I was reading the docs and they say:
It is critical that transaction functions are “pure” - as in they only use the information passed to them via explicit arguments. This is essential for deterministic operation. Actions like generating UUIDs or accessing the system clock would be examples of impurity that can easily lead to non-determinism and break the transactional guarantees that XTDB offers.
So it uses the examples of generating UUIDs and reading the system clock as impure actions.
The action of reading the database state in ‘transaction function’ could be considered a side effect as well, but if I understand you correctly you are saying that reading the database in ‘transaction function’ is considered pure in this scenario. Correct?
For example, if I want to have a document in the DB that auto-increments an integer whenever I perform a put operation.
That’s right, yep 
1 Like