COMMIT WORK AND WAIT handling within Gateway changesets

[woutdejong]

method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END.

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

  endmethod.

Experts,

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.

[Andre_Fischer · Accepted solution]

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

Andre

[KKilhavn · Accepted solution]

I just ran into a problem related to this, and would appreciate any feedback from you Andre or any of the other gurus in your department (or indeed anyone else reading this).

I work on the backend (service implementation) for a solution where the client is developed with Hybrid Application Toolkit and has offline capability. In the service implementation I have created update function modules, and just now I tested the update conflict handling. I made two changes to the same entity offline, and when I synchronized the second update failed due to Etag mismatch. A second synchronization attempt was made and update number two was accepted, which is a pretty strong indication to me that this problem results from a race condition. The first update hasn't been commited before the second request is being processed, and therefore it fails to match the Etag - so how can I ensure that the first update has been commited. Well, there's that commit & wait statement, and there's *possibly* other solutions.

We use weak Etag with the latest changed timestamp, but that shouldn't really be of any significance here since it is a timing issue.

My question then is; would you consider it a bad solution to add a "commit work and wait" statement in the implementation of changeset_end to ensure the update function modules have completed before the next request is processed, or is this an acceptable (or even common) way to solve such race conditions?

[Andre_Fischer · Accepted solution]

Would it be possible to use the deferred mode in $batch?

https://help.sap.com/viewer/68bf513362174d54b58cddec28794093/7.51.0/en-US/94a126519eff236ee10000000a...

Here as a developer you would get the content of a $batch request and can work on it as you like.

Regards,

Andre

[KKilhavn · Accepted solution]

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.

[woutdejong]

Stefan,

The issue at hand is very much ABAP backend related, so I'm not sure if your comment helps.

Can you elaborate?

[woutdejong]

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

[srg]

This UI5 behavior is the consequence of the ODataModel configuration in UI5.
It is easy to change this.

Regards,

Stefan