I have a stored procedure (called from Appian’s Execute Stored Procedure smart service) that reads from a view and then creates, updates, or deletes rows in a materialized table that is also sourced from that same view.
The view is heavily used by multiple applications, so I created the stored procedure smart service to read the updated values from the view and reflect them in the materialized table. This process is triggered by various create or update forms across different applications.
Most of the time the stored procedure works, but sometimes it fails with the following error:
Deadlock found when trying to get lock; try restarting transaction
How can I reduce or avoid these deadlocks?
Discussion posts and replies are publicly visible
I do not understand why you directly modify data in that materialized view. Isn't the idea that it updates itself?
This is said with the caveat that the best answer will depend on your database technology, what exactly your use case is, and how complex the queries are to the materialized tables (not the view). Understanding the latter is not easy, depending on how many queries there are to the tables.
You'll need to understand what the deadlock is actually on - my instinct says that is mostly likely the 'deletes', but the database logs hopefully provide a real answer.
Here are things I have done in the past in similar situations:
With proper locking it was possible to have Appian process an average of 1200 web API requests in a burst during business hours, with global identifier results returning to the caller of the API in under 1000ms and also (eventually, with refinement) without any performance impacts to the users.
Is it not possible to use the Data Fabric for your purposes? The Data Fabric is, effectively, a materialized layer on top of your database. It has a small learning curve, and older applications need to be refactored into it, but it serves its purpose extremely well.