Skip to Content

COMMIT WORK AND WAIT handling within Gateway changesets


     commit work and wait. 
"wait required because of no tolerance of delay in update task



Can we somewhere configure or customize in SAP NW Gateway the behavior of COMMITs (transaction handling)?

We have a requirement that we MUST wait for the update task to release the locks on SAP objects. We now have implemented the CHANGESET_END method (see above), but wondered if there is a generic switch or piece of customizing that deals with this.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Jun 02, 2017 at 09:37 AM

    Hi Wouter,

    your question is not 100% clear to me.

    You wrote that you have the requirement that you "cannot wait for the update task to release the locks on SAP objects.".

    But if you use "COMMIT WORK AND WAIT" it is exactly the opposite behaviour. You wait as long as it takes for the system to persist the changes on the underlying database.

    The SAP Gateway framework by default performs a commit work at the end of a change set since this is the end of a LUW. We do however not perform any other COMMIT WORK when doing updates or creates. This has to be done be the service implementation.

    That said if you explicitly want to wait for the update task to finish your implementation is correct.

    Best Regards


    Add comment
    10|10000 characters needed characters exceeded

    • Sorry about not getting back to reply to this earlier. Unfortunately I can't recall now the exact details of this issue :-)
      However, a lot of changes have been made both to the client and the backend, and we have solved the problems related to multiple updates from a single client.

  • Aug 08, 2017 at 02:33 PM

    Sorry Andre for taking 2 months to respond... Still, thank you anyway.

    Indeed we are required to wait for as long as it takes to commit the changes to the db (and also release the locks). Just that I generally regard explicit COMMITs as smelly code, especially if an encapsulating framework (like GW, or the soap runtime) takes care of this.

    BTW, we now always put the COMMIT WORK AND WAIT in the CHANGESET_END method, as we have seen too many times that UI5 (1.38) issues a MERGE entity and GET entity request in 1 $batch (fortunately in that order) that resulted in the old, previous value being returned instead of the updated value from the MERGE.

    Cheers, Wout

    Add comment
    10|10000 characters needed characters exceeded