Transaction (Process ID xxx) was deadlocked on lock resources with another process an
Application Type
Traditional Web
Platform Version
11.14.1 (Build 34445)

i hit below error: 

Transaction (Process ID 234) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 


but the thing is, i don't know how to release the deadlock without sql server db since the platform is on the cloud.

i tried to re-deploy the whole application which will redeploy the entities and those logics, i assumed that the deployment will reset the database, but it didn't.

i also tried to restart the frontend server, but also not working.

anyone hit this issue before?  pls do me a favor if you know how to get it fixed.


A deadlock is also called 'a deadly embrase'.
When the database management system (DBMS, SQL Server in your case, Oracle in my environment) detects a deadlock this is what happens:

Two processes work with the exact same data. What you don't see is that records in the tables (and indexes) are (implicitly and sometimes explicitly (GetForUpdate)) being locked during the processing of your SELECT, UPDATE and DELETE statements.

A deadlock occurs when
- Process A locks record Z and wants to lock record Y
and at the same time
- Process B holds a lock on record Y and wants to lock record Z

As you can see the processes are waiting on each other to release the lock on the records they need.
That will never happen and thus the DBMS decides to kill one the two processes to prevent that this
problem will grow bigger when other processes join the embrase and the problem is to become worse,

The only way to prevent this is to do proper analysis of the access paths to the data by the concurring processes and take charge of the sequence in which database records are being locked.
Please note that this is just a tip of the iceberg and find out more about locking, lock promotion, database transaction scope, and locking types (optimistic, causious, paranoid).

Especially with timers in a multi-tenancy situation this problem will occur sooner or later...

Please let me know when you need more info or explanation.

Cheers, Toine

Hi Toine,

Thanks for the explanations. 

I suddenly realise why this issue happened,  we didn't add any index on the table, All the SQL statement will use table scan and lock all the records. 

Really really appreciated.   

Cheers, Nico



Hi NicoNico,

Can you please share some context?

- When does dis happen?
- Please share the error messages involved
- Are you aware of what a Database Deadlock is?

Cheers,
Toine

the logic is as below:

we have one multiple tenant application, and we have a timer job which is also for multiple tenant.  

there is a batch update in this timer job,  we don't specify the tenant id in the SQL; while the timer is running, it often hits the deadlock issue at some tenant.

error message: Transaction (Process ID 237) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 


yesterday this error suddenly disappeared, but it happened again today.



i have one idea now, but i don't know if it's correct or not:

1. expose the tenant_id for that certain table which needs to be batch updated.

2. add the tenant_id as the input parameter for that batch update SQL

3. assign the site.tenantid as the input parameter


but i don't know if this can fix the issue or not.

Hi as you dont own the db. think it is better you open a support case especailly if this ur prod envrioment

Hi there,


It seems a deadlock when running a query in your DB try this on sql or other DB


select xpto nolock from xptotable

thx a lot. i understood that we probably encountered the deadlock issue.

but the SQL is an advanced query - batch update, not the select query.  since we cannot access the db directly, i cannot release the deadlock from the system table myself. :( 


as i explained:  we have multiple tenants under this app, and we have a timer job including this batch update job to sync data.


while the timers run as schedule, one timer often hit the deadlock issue as above error msg.


I tried to disabled the timer from one tenant and activated again after few seconds, the error msg suddenly disappeared.  but i don't know the root cause and if the error will happen again in the future.


I also want to know how the outsystems handle the concurrent batch update in the multiple tenant apps and the database security level.


A deadlock is also called 'a deadly embrase'.
When the database management system (DBMS, SQL Server in your case, Oracle in my environment) detects a deadlock this is what happens:

Two processes work with the exact same data. What you don't see is that records in the tables (and indexes) are (implicitly and sometimes explicitly (GetForUpdate)) being locked during the processing of your SELECT, UPDATE and DELETE statements.

A deadlock occurs when
- Process A locks record Z and wants to lock record Y
and at the same time
- Process B holds a lock on record Y and wants to lock record Z

As you can see the processes are waiting on each other to release the lock on the records they need.
That will never happen and thus the DBMS decides to kill one the two processes to prevent that this
problem will grow bigger when other processes join the embrase and the problem is to become worse,

The only way to prevent this is to do proper analysis of the access paths to the data by the concurring processes and take charge of the sequence in which database records are being locked.
Please note that this is just a tip of the iceberg and find out more about locking, lock promotion, database transaction scope, and locking types (optimistic, causious, paranoid).

Especially with timers in a multi-tenancy situation this problem will occur sooner or later...

Please let me know when you need more info or explanation.

Cheers, Toine

Hi Toine,

Thanks for the explanations. 

I suddenly realise why this issue happened,  we didn't add any index on the table, All the SQL statement will use table scan and lock all the records. 

Really really appreciated.   

Cheers, Nico



Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.