In Dynamodb paper 2022 https://www.usenix.org/system/files/atc23-idziorek.pdf, it's said that Transactions do not acquire locks. However in pseudo code in Listing 4
def processCommit ( CommitInput input):
item = readItem (input)
if item == NONE
OR item.ongoingTransaction != input.transactionId :
return COMMIT_FAILED
applyChangeForCommit ( item , input.writeOperation )
item.ongoingTransaction = NONE
item.timestamp = input.timestamp
return SUCCESS
Is the condition item.ongoingTransaction != input.transactionId a form of lock? Only 1 transaction can process the item and other transactions need to wait until the transaction finish.
Also, according to 2 phase commit, 2nd phase (commit phase) will eventually success but i see the code can return COMMIT_FAILED. Is this something that only Dynamodb do?
I tried looking into lock-free and wait-free discussions but still not sure how to explain that item.ongoingTransaction != input.transactionId is not a lock.
Answer
Transactions do pessimistic locking, but not quite the same as relational databases. The transaction coordinator will hold the items that are in flight, which acts as a lock, while the prepare phase is initiated until the commit either succeeds or fails, all subsequent writes to that item will fail with a `TransactionConflictException` this is true for even non transactional writes.
A transactional conflict can occur during concurrent item-level requests on an item within a transaction. Transaction conflicts can occur in the following scenarios:
A PutItem, UpdateItem, or DeleteItem request for an item conflicts with an ongoing TransactWriteItems request that includes the same item.
An item within a TransactWriteItems request is part of another ongoing TransactWriteItems request.
An item within a TransactGetItems request is part of an ongoing TransactWriteItems, BatchWriteItem, PutItem, UpdateItem, or DeleteItem request
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html