optimistic concurrency/row versioning support.

I couldn’t find any issues created regarding optimistic concurrency so here we go…

Since Hasura handles DB transactions on its own, it’s a little bit more difficult to implement something like optimistic concurrency for db updates.

For those who don’t know, Optimistic concurrency is a way to solve concurrency issues when multiple parties attempt to update a value at the same time. Example:

Another example: Inventory quantity count - we would want the inventory to always reflect the true inventory count as concurrent orders come in. Definitely don’t want updates to be lost.

I know Hasura isn’t really an ORM, but lots of existing ORMs support this feature out of the box where you can just “turn on” optimistic concurrency for any specified table.

It would be neat to also “turn on” this feature for a table in hasura as well.

I am not even sure if implementing this is currently possible in Hasura.

Update: Looks like there is an _inc param as part of update mutation that could be used if updating simple integer columns (like inventory count). This makes it so that we avoid the read-modify in read-modify-write cycle, and no need for complex locking/concurrency solution with a DB constraint (column > 0) for safety. Only works for simple integer use cases with simple business logic like (column > 0) though. Still the same issue exists for any none-integer column updates or complex business logic.

[tirumaraiselvan]

Thanks for the explanation! Indeed, there is a problem if you are running some business logic outside of a transaction.

To solve this, we can either support a graphql open transaction protocol (something we have been exploring) or we can explore optimistic concurrency control mechanisms.

[smblee]

@tirumaraiselvan thanks for the reply!

I understand wrapping around transaction would solve this, and I also understand everything within a query/mutation block are wrapped around a transaction (which is good).

But imagine a case where you have to do the following:

1. Get all the order items with all the products and their current inventory quantity using hasura query (transaction #1)
2. Within the business logic, update the quantities and create a update_product_inventory_input[] for all the products to be updated.
3. Call the update mutation with the created input objects using hasura mutation (transaction #2)

Imagine multiple calls are updating the same product quantities at around the same time.

Since #1 and #3 happen in different transaction blocks, it could be that during #2 (which could take some time), another call already could have updated the quantity which outdates the quantity fetched from #1, therefore whatever update that happened during #2 is will be based on old/outdated inventory quantities.

One solution to this (if you can create your own transactions), would be to wrap all 1~3 in a transaction block (the downside being you could potentially have a long lasting transaction)