Brief Intro of what happens in Lost Updates?
A simple example which will make you understand Lost Update.
For an example:
Session 1: User A reads record 1
Session 2: User B reads record 1
Session 1: User A updates record 1
Session 2: User B updated record 1
User B have not seen the record updated by User A and updated the existing record resulting in Lost Updates.
How can we tackle it programmatically?
There are the other solutions too such as generating a random number and assigning the number to a record.
Let’s see how we can handle these in ODATA
It’s too cumbersome to do the above things and put into the service with Hana. Here where the etag functionality of ODATA services comes into picture. We need to take care of few things and we are ready to save database from lost updates.
These mechanism can be applied both on the tables and views. For views you have to specify the key.
Here is an example of simple service that does the task for us:
A simple example which will make you understand Lost Update.
For an example:
Session 1: User A reads record 1
Session 2: User B reads record 1
Session 1: User A updates record 1
Session 2: User B updated record 1
User B have not seen the record updated by User A and updated the existing record resulting in Lost Updates.
How can we tackle it programmatically?
- We maintain a time stamp field on the record and give it to the user who is requesting the record. Now when the user wants to save the modified record we just check it again time stamp of the record if the time stamp are not same, record have been updated before and return an error.
- We do the checksum of all the fields. Now when you user go back to update we just check the checksum if the checksum are not same we return an error.
There are the other solutions too such as generating a random number and assigning the number to a record.
Let’s see how we can handle these in ODATA
It’s too cumbersome to do the above things and put into the service with Hana. Here where the etag functionality of ODATA services comes into picture. We need to take care of few things and we are ready to save database from lost updates.
These mechanism can be applied both on the tables and views. For views you have to specify the key.
Here is an example of simple service that does the task for us:
Now when you do get the data from the service you will always get the etag in the metadata. As show in screen shot below:
Look at the screen shot we get the etag in request from server.
Now the ETags comes with two different options weak and strong tags.
- A weak ETag could be considered the last updated time or the version of a document. Weak ETags are prefixed with the “W/” to indicate they are weak.
- A strong ETag is considered if the entire representation of the entity is considered binary identical so all fields are compared and typically a hash of the entity is used as the strong ETag. Strong ETags do not have the leading prefix weak ETags do.
We will go here with weak tag. Screen shot from using the postman:
If-match header have two options one is the value etag value and the other can be *. If value is provided it will validate against the token and for * it will not validate it.
If you update the record twice it will give you error as “412 precondition failed” because the etag token is changed.
Can find for information about the etags at:
Source: scn.sap.com
No comments:
Post a Comment