0

I have a Spring Boot application (2.2.5 RELEASE) that sync (not reactive) writes to AWS DocumentDB wo declaring any explicit transaction semantics from application. We are using MongoOperations without declaring an explicit MongoTransactionManager

In this setup, for MongoDB 4.X Replica-Set, we get "auto-committed" writes if an explicit transaction is not initiated by client. see here

However, we would like to understand, using the same Mongo Java driver version 3.11.2 , compatible with MongoDB Server version 4.2.X, when we execute a WRITE operation on a DocumentDB Cluster (having a replica Set), without initiating explicit Transaction from Client (i.e. spring boot app), when or how exactly the database commit takes place? We have seen closely spaced updates-after-insert (within <50 ms) to fail stating update wasn't able to find the inserted record.

It appears that the same behavior as MongoDB, i.e. "auto-committed" is probably not applicable with "DocumentDB". In that case how WRITEs are committed?

Can someone help us understand the underlying behavior? We couldn't find any relevant section in the AWS DocumentDB Documentation that elaborates on the WRITE Ops wo Transactions.

Also, does DocumentDB use a Single Threaded WRITE approach on a collection or how is it?

Divs
  • 1,578
  • 2
  • 24
  • 51

1 Answers1

0

Amazon DocumentDB uses a distributed storage volume and data is replicated 6 times across three availability zones. The distributed storage uses 10GB chunks as logical unit. When writing data, Amazon DocumentDB ensures that all writes are durably recorded, using a write quorum of 4. After 4 copies of data are written to storage, data can be considered committed and the Primary instance will send an acknowledgment to the client. Data is further copied to other 2 chunks to a total of 6, as mentioned before.

There is good information in the documentation about read and write consistency, but let me know if you require further clarification.

Mihai A
  • 351
  • 1
  • 4