Re: Race condition between row create and update

gali · 01-04-2023 10:38 AM

Hi,

It seems I'm experiencing a race condition:

I've configured a Behavior in my form view: Once the form is saved -> run 'Data: set the values of some columns in this row' (edit one of the fields). Looking in the chrome developer tools, I see two calls are sent to AppSheet API - one to create the row and another to edit it:

The update is working correctly. Still, then there is a screen flickering, and the original value before the set data action overrides the edited value again. Eventually, the initial value is saved to the DB, not the new one.

My app is working against Postgres (RDS) DB

https://www.appsheet.com/api/template/<row_id>/table/<table_name>/row
https://www.appsheet.com/api/template/<row_id>/table/<table_name>/row/update

WillowMobileSys

@gali wrote:

Still, then there is a screen flickering,

Not sure what this means. You'll need to describe the experience in more detail.

@gali wrote:

It seems I'm experiencing a race condition:

Possibly. It depends on how you have implemented the row add and then the edit and maybe if you have any "Reset on Edit" properties set.

There is common misunderstanding in how AppSheet platform updates. It is a ROW based processing system. Meaning each EDIT represents a state of the entire row. Whether it is one column changed or multiple columns changes by that one action, they are sent as a single row edit Additionally, AppSheet is a distributed system - meaning each user has their OWN copy of the complete dataset. This is by design for efficiency and performance in a mobile system.

Now, image two users making a change to the SAME row at the same time BUT each is changing different data. Users one change column C from blank to value "abc" but user 2 doesn't change it at all. Again each edit send the ENTIRE row state as a single edit.

If User 1's edit is applied to the server first, column c will change from blank to "abc". Then when User 2's edit is applied, column C changes back to blank because User 2 didn't change that column BUT the entire row state is applied. Last row edit applied wins!

You mentioned using the AppSheet API. EACH API call is essentially treated like another user - having its own set of data and applying each row change as a single edit back to the server datasource. Typically, you would want API calls/automation to run in a parallel/multi-threaded fashion. In your use case maybe not and I believe there's configuration you can use to control sequential processing of the Bots. I don't know how well it works or expectations.

Bottom line is that you want to implement your app such that, where-ever possible, processing can be done independent of all other processing. To best accomplish this you will want the data properly structured into smaller contained entities/tables. For instance, creating one big table will lots of unrelated columns will increase the likelihood that two processes or users via for updates on the same row.

Additionally, you can help avoid the "race" condition by combining edits into a single action so they are sent as a single row edit. This is not always possible but something to look for.

I hope this helps!

gali

@WillowMobileSys

Thank you for your answer.

The behavior I'm trying to implement, is to update one column right after the row is created.

I've configured the in the behavior of the Form view to run the update action, I'm not using the API directly, but I saw in the developer tools that this is what is happening under the hood.

So its the same user, same row..

The screenshot is taken from the Form view (there used to be there the update action instead of **auto**

WillowMobileSys

Ok. Got it! This implementation you described should not have any "race" condition problems. While there will be 2 row edits performed on the device side and they will be processed in order.

Another potential gotcha that may not be apparent is if you have any automation triggered based on row adds, updates or both. If so and they perform additional edits then they are likely contributing to this issue.

Do you have any Bots potentially triggering based on a row add/update from your use case?

gali

No, I don't have any bots. that was the only one

WillowMobileSys

@gali wrote:

No, I don't have any bots. that was the only one

This statement is contradicting itself. I'll assume you mean that you have ZERO Bots only the action attached to Form Save.

There must be something unusual about your implementation. It would be best to show us what you have implemented in the Form Saved action to be able to help further.