Does DynamoDB have a mechanism to lock a row for reading?

Question

Does Amazon DynamoDB have a mechanism to lock a row for reading? Something similar to what's described for PostgresQL at https://www.2ndquadrant.com/en/blog/what-is-select-skip-locked-for-in-postgresql-9-5/

I could not find any documentation, hence wanted to confirm.

EDIT: I want to lock a row so that "reads" do not get this row while it is locked. It is available for reading again when the lock is released.

EDIT2: Purpose is to emulate a queue for distributed processing. Different clients need to pull an item from a table for processing. See the above link to get an idea of how this is achieved in PostgresQL.

Answer 1

DynamoDB does not support this.

RDMBSs associate row locks with a transaction and associate transactions with a single client connection to the database (and automatically releasing those locks if the connection holdng them goes away) but DynamoDB is connectionless -- everything between your code and the database happens over a series of uncorrelated HTTPS requests. (And, of course, DynamoDB also isn't an RDBMS).

DynamoDB thus has no concept like SELECT ... FOR UPDATE (which locks the found rows and prevents other transactions from seeing them, either by implicit read-blocking or explicit row skipping) and has none of the capabilities that would follow from that.

The closest thing -- which admittedly is not particularly close -- would be using consistent reads and conditional writes (which allow updating an attribute only if it already matches an expected state) to check, set, and clear a user-defined locking attribute that flags the state of each record and perhaps leaves a trail of how the record came to be in that state (populated, e.g., with something like "record locked at timestamp w by thread x from pid y on host z," helpful when figuring out what happened if records get stuck in the locked state).

Answer 2

You can achieve this by using optimistic locking or pessimistic locking.

Optimistic locking will detect if another concurrent thread has updated the row before while you are working on it.

Pessimistic locking uses the transactions DB concept. This will guarantee that only transactions are implemented one by one. You can put multiple queries in the same transaction to apply the idempotent concept. In the two solutions, you will still need to code the conditions by yourself it won't automatically put transactions in queues. It will just return an indicator for example (an update could be rejected because it already happened by another concurrent thread).

reference: https://dynobase.dev/dynamodb-locking/