How do I use optimistic without the use of DynamoDBMapper?
Developers often will refer to this documentation: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html. Often times there is the assumption that optimistic locking cannot be achieved without DynamoDBMapper. We will discuss when optimistic locking is a good option and how to achieve it with condition and update expressions.
Before you can use optimistic locking, make sure that you have and understand the following:
- DynamoDB table with items
- A conditional exception is thrown when you are using optimistic locking with @DynamoDBVersionAttribute and the version value on the server is different from the value on the client side
- A conditional exception is thrown when you have conditional constraints in place while saving data
- Understand Conditional Expressions
Example
An example use case for Optimistic Locking would be if in an application, a database that has multiple users trying to modify a record at the same time. Concurrent writes being performed could be an issue due to the high possibility of inconsistencies. In the situation example below, the table handles laptop rentals. One column would contain the LaptopId (example will use the ID. number "194438"), another would be the LaptopCount, and finally the RentalLimit. On the client-side application, there would be logic in place that would decrease LaptopCount when a rental is made and increase LaptopCount when there is a return.
Example Table:
LaptopId | LaptopCount | RentalLimit | versionid |
---|---|---|---|
194438 | 100 | 0 | 0 |
To reiterate, we are looking at if two client applications is trying to load LaptopId, and both clients attempts to update the record at the same time as each other.
Original value for LaptopCount will be 100 and there are two concurrent transactions. One client updates the LaptopCount by decreasing it by 60. At the same time a second client is updating the LaptopCount value decreasing the value by 70. The value changes depending on which clients request got processed first. Since both clients are under the impression that there are 100 laptops, if client one’s request gets processed first the second clients request will have crossed the limit and will fail. In this situation it would be ideal to have the clients read the current records then apply the changes. If the request does not cross the RentalLimit, then it should successfully write or send back. If it does cross the RentalLimit, a message informing it cannot be done.
To ensure that your items on the client-side are updating properly in Amazon DynamoDB, optimistic locking is a good option. That being said, it is completely acceptable to use optimistic locking without a mapper. With the use of DDBMapper, you do not need to have to write your own conditionals.
Now thinking of the situation above with Optimistic locking implemented, both clients will read the same records, the version number would show. If both clients put in a request with the same version number concurrently it would be dependent on which request gets processed first. The first processed request would contain the matching version number on the record and the request would be fulfilled. This will increment the version number. The second clients request was sent at the same time, but processed after. This means the record on the database has a new version number that does not match the one in the request and the request would fail. The second client would now retrieve new version number and details.
Conditional Expressions is helpful in the case of Optimistic Locking. You will have to use conditional writes so that the write operation being sent can only be performed after conditions are met. Using Version numbers that are associated with each record is the method to start using optimistic locking. This is so that the records can be matched if it is the current version of table.
Overview of the Example with Optimistic Locking implemented:
- When a client sends a request, the request should include the same version number on the table so we would read the current item
- While this write operation request is sent, there will be an initial cross referencing of the version number in the table and the request. If the version numbers match, the write operation follows the flow and if the limit is not crossed the request succeeds and the version is changed.
- If the version number in the request and the database are mismatched, the write operation would fail. This would cause the client to get the latest version of the record. The request should then be sent again with the new version number.
Related Information:
Contenido relevante
- OFICIAL DE AWSActualizada hace 9 meses
- OFICIAL DE AWSActualizada hace 4 meses