Skip to Content


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?


  1. 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.  
  2. 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:

Service.PNG


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:Etag-Token.PNG

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:

Postman-putRequest.PNG

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 more information about the etags at:

OData ETag Support – SAP HANA Developer Guide for SAP HANA Studio – SAP Library

Hope this will help. 🙂

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Lucas Oliveira

    Hi Pratik,

    Cool post!

    My only observation to what you wrote is: would be nice to see more background information with references to sources here.

    That makes it easier for readers to understand where you’re coming from and what’s out there 😉


    For instance, the scenario described by you is just part of a lock-less optimistic concurrency control strategy. The Etag here is provided by the HTTP protocol itself and used by OData real nicely .

    The HANA OData official documentation related to this topic has additional info and specializations for HANA.

    Anyhow, real nice to see the internals working 😉

    Thanks for sharing!

    (0) 
      1. Lars Breddemann

        Cannot agree with Lucas any more: this is a really good blog post.

        My only suggestion would be to rethink the title. My initial thought when reading the title was: “Oh, well, there’s another rant from someone who doesn’t get transaction isolation…” But you nicely show that this is not the case at all.

        Good work!

        (0) 

Leave a Reply