Clarification on XTDB's ACID transaction behavior

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)

1 Like

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 :slight_smile:

James

2 Likes