Hi
I have a question to ask.
I understand from some technical documentation that after the transaction commits, the changes are applied asynchronously to the RegularDB and then deleted from the IntentsDB.
Because this apply is asynchronous, it is possible that a read operation may come in before the apply completes, at which point regularDB may not have the data yet.
So, my question is: for non-transactional read operation, if there is a record in intentDB and the status has been marked as committed, but it has not been written to the regularDB case, will the data in intentDB be read first? If not, is this data considered uncommitted and cannot be read?
Hi, yes there’s is an intents aware iterator that reads from both LSM-tree. All reads go through it.
There is no “non transactional read” (except with xCluster non-transactional replication but that’s different topic). Even the follower reads use the intents aware iterator (with some optimisation to avoid reading the transaction status if not needed for the read time snapshot)
There is a non transactional write which bypasses the intents DB and make writes immediately visible. So the reads see the new value from the regularDB with the intents aware iterator
Hi @FranckPachot
So the description of the Yugabyte Docs AI in the screenshot below should be wrong?
Thanks a lot.
Thanks for reporting. Yes, I think that AI tries to build an answer when asked for “non-transactional read” and as this term is never used, it extrapolates it from non-transaction writes 
Before answering your questions, I also asked AI to see what comes and also got a wrong answer taken from xCluster replication that can be set as non-transactional but that has nothing to do with intentsdb 
Okay，I got it now.
Thanks a lot.
YCQL tables CAN be non-transactional. Maybe it’s used in that scenario.