DynamoDB conditional write

• By default, DynamoDB writing operation ( PutItem, UpdateItem , and  DeleteItem) are unconditional : wherein each operation overwrites an existing item with the specified primary key.
• DynamoDB conditional write can be selectively support these operations. Conditional write the project will be successful only when the property meets one or more conditions are expected. Otherwise, it returns an error. Conditional write in many cases very useful. For example, you might want to  PutItem operate successfully only in the presence of the project with the same primary key is not yet. Or, if one of these items has a specific value of a property, you can prevent  UpdateItem the operation to modify the project.
• Conditional write useful if multiple users attempt to modify the same project. Consider the following diagram, in which two users (Alice and Bob) are working on the same project DynamoDB table.

Conditional write Idempotence

If a condition check to be updated on the same property, the conditional write can be idempotent  of. This means that when property values only when certain items with you in the request matches the value that they have expectations, DynamoDB only perform a given write request.

For example, suppose you send a  UpdateItem request to increase 3 increments of a project  Price, but only  Price do this for only 20 currently. In the time between sending the request but the results have not yet been returned, a network error occurred, you do not know whether the request was successful. Since this condition is written idempotent, you can retry the same  UpdateItem request, DynamoDB will only  Price update the current project is 20.

 

What is Idempotence

HTTP / 1.1 is defined to be idempotent it is: one primary and multiple resource requests to the resource itself should have the same result (except for the network timeout issues). In other words, any of its multiple executions were carried out with the same impact once the impact of the resource itself have on .

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

We should focus on a few points:

1. Idempotency not just one (or more) requests no adverse effects on resources (such as querying a database operation, no additions and deletions, and therefore does not have any impact on the database).

2. Idempotent the first time also includes a request for resources to produce side effects, but many subsequent requests will not produce adverse effects on resources.

3. Idempotent concern is whether the side effects after repeated requests for resources generated, rather than focusing on results.

4. Network timeouts and other issues, not idempotent discussion.

Idempotence is a system service outside a commitment (and not achieve), as long as the commitment to a successful call interface, multiple calls to external impact on the system is consistent. Declared idempotent service call fails think outside the norm, and there must be retried after a failure.