execute_transaction
¶
execute_transaction(
transact_statements: ParameterizedStatements,
*,
config_overrides: Optional[DynamoDBClientConfig] = None,
client_request_token: Optional[ClientRequestToken] = None,
return_consumed_capacity: Optional[ReturnConsumedCapacity] = None,
) -> ExecuteTransactionOutput
This operation allows you to perform transactional reads or writes on data stored in DynamoDB, using PartiQL.
The entire transaction must consist of either read statements or write statements, you cannot mix both in one transaction. The EXISTS function is an exception and can be used to check the condition of specific attributes of the item in a similar manner to ConditionCheck in the TransactWriteItems API.
Parameters:
-
transact_statements(ParameterizedStatements) –The list of PartiQL statements representing the transaction to run.
-
client_request_token(Optional[ClientRequestToken], default:None) –Set this value to get remaining results, if
NextTokenwas returned in the statement response. -
return_consumed_capacity(Optional[ReturnConsumedCapacity], default:None) –Determines the level of detail about either provisioned or on-demand throughput consumption that is returned in the response. For more information, see TransactGetItems and TransactWriteItems.
Raises:
-
IdempotentParameterMismatchException–DynamoDB rejected the request because you retried a request with a different payload but with an idempotent token that was already used.
-
InternalServerError–An error occurred on the server side.
-
ProvisionedThroughputExceededException–The request was denied due to request throttling. For detailed information about why the request was throttled and the ARN of the impacted resource, find the ThrottlingReason field in the returned exception. The Amazon Web Services SDKs for DynamoDB automatically retry requests that receive this exception. Your request is eventually successful, unless your retry queue is too large to finish. Reduce the frequency of requests and use exponential backoff. For more information, go to Error Retries and Exponential Backoff in the Amazon DynamoDB Developer Guide.
-
RequestLimitExceeded–Throughput exceeds the current throughput quota for your account. For detailed information about why the request was throttled and the ARN of the impacted resource, find the ThrottlingReason field in the returned exception. Contact Amazon Web Services Support to request a quota increase.
-
ResourceNotFoundException–The operation tried to access a nonexistent table or index. The resource might not be specified correctly, or its status might not be
ACTIVE. -
ThrottlingException–The request was denied due to request throttling. For detailed information about why the request was throttled and the ARN of the impacted resource, find the ThrottlingReason field in the returned exception.
-
TransactionCanceledException–The entire transaction request was canceled.
DynamoDB cancels a
TransactWriteItemsrequest under the following circumstances:-
A condition in one of the condition expressions is not met.
-
A table in the
TransactWriteItemsrequest is in a different account or region. -
More than one action in the
TransactWriteItemsoperation targets the same item. -
There is insufficient provisioned capacity for the transaction to be completed.
-
An item size becomes too large (larger than 400 KB), or a local secondary index (LSI) becomes too large, or a similar validation error occurs because of changes made by the transaction.
-
There is a user error, such as an invalid data format.
-
There is an ongoing
TransactWriteItemsoperation that conflicts with a concurrentTransactWriteItemsrequest. In this case theTransactWriteItemsoperation fails with aTransactionCanceledException.
DynamoDB cancels a
TransactGetItemsrequest under the following circumstances:-
There is an ongoing
TransactGetItemsoperation that conflicts with a concurrentPutItem,UpdateItem,DeleteItemorTransactWriteItemsrequest. In this case theTransactGetItemsoperation fails with aTransactionCanceledException. -
A table in the
TransactGetItemsrequest is in a different account or region. -
There is insufficient provisioned capacity for the transaction to be completed.
-
There is a user error, such as an invalid data format.
DynamoDB lists the cancellation reasons on the
CancellationReasonsproperty. Transaction cancellation reasons are ordered in the order of requested items, if an item has no error it will haveNonecode andNullmessage. TheNonecode is returned as the literal string"None", not a null or absent value; the message field is omitted entirely for an item that has no error. This is important to note when using an SDK that surfaces the code as an optional or nullable type.Cancellation reason codes and possible error messages:
-
No Errors:
-
Code:
None -
Message:
null
-
-
Conditional Check Failed:
-
Code:
ConditionalCheckFailed -
Message: The conditional request failed.
-
-
Item Collection Size Limit Exceeded:
-
Code:
ItemCollectionSizeLimitExceeded -
Message: Collection size exceeded.
-
-
Transaction Conflict:
-
Code:
TransactionConflict -
Message: Transaction is ongoing for the item.
-
-
Provisioned Throughput Exceeded:
-
Code:
ProvisionedThroughputExceeded -
Messages:
-
The level of configured provisioned throughput for the table was exceeded. Consider increasing your provisioning level with the UpdateTable API.
This Message is received when provisioned throughput is exceeded is on a provisioned DynamoDB table.
-
The level of configured provisioned throughput for one or more global secondary indexes of the table was exceeded. Consider increasing your provisioning level for the under-provisioned global secondary indexes with the UpdateTable API.
This message is returned when provisioned throughput is exceeded is on a provisioned GSI.
-
-
-
Throttling Error:
-
Code:
ThrottlingError -
Messages:
-
Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html.
This message is returned when writes get throttled on an On-Demand table as DynamoDB is automatically scaling the table.
-
Throughput exceeds the current capacity for one or more global secondary indexes. DynamoDB is automatically scaling your index so please try again shortly.
This message is returned when writes get throttled on an On-Demand GSI as DynamoDB is automatically scaling the GSI.
-
-
-
Validation Error:
-
Code:
ValidationError -
Messages:
-
One or more parameter values were invalid.
-
The update expression attempted to update the secondary index key beyond allowed size limits.
-
The update expression attempted to update the secondary index key to unsupported type.
-
An operand in the update expression has an incorrect data type.
-
Item size to update has exceeded the maximum allowed size.
-
Number overflow. Attempting to store a number with magnitude larger than supported range.
-
Type mismatch for attribute to update.
-
Nesting Levels have exceeded supported limits.
-
The document path provided in the update expression is invalid for update.
-
The provided expression refers to an attribute that does not exist in the item.
-
-
-
-
TransactionInProgressException–The transaction with the given request token is already in progress.
Recommended Settings
This is a general recommendation for handling the
TransactionInProgressException. These settings help ensure that the client retries will trigger completion of the ongoingTransactWriteItemsrequest.-
Set
clientExecutionTimeoutto a value that allows at least one retry to be processed after 5 seconds have elapsed since the first attempt for theTransactWriteItemsoperation. -
Set
socketTimeoutto a value a little lower than therequestTimeoutsetting. -
requestTimeoutshould be set based on the time taken for the individual retries of a single HTTP request for your use case, but setting it to 1 second or higher should work well to reduce chances of retries andTransactionInProgressExceptionerrors. -
Use exponential backoff when retrying and tune backoff if needed.
Assuming default retry policy, example timeout settings based on the guidelines above are as follows:
Example timeline:
-
0-1000 first attempt
-
1000-1500 first sleep/delay (default retry policy uses 500 ms as base delay for 4xx errors)
-
1500-2500 second attempt
-
2500-3500 second sleep/delay (500 * 2, exponential backoff)
-
3500-4500 third attempt
-
4500-6500 third sleep/delay (500 * 2^2)
-
6500-7500 fourth attempt (this can trigger inline recovery since 5 seconds have elapsed since the first attempt reached TC)
-
-
UnknownServiceError–The service returned an error code this client does not model.
Source code in docs_src/capo_dynamodb/_services/dynamo_db.py
1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 | |