Mendix Updates Causing Database Locks

Hi there We are enhancing and supporting a Mendix application (EZflow) in a call centre environment for a financial services company (Direct Axis). The application accepts and captures leads and uses workflow to direct the leads to call centre agents. We have been experiencing periods of extreme slowness to the point where the agents can't access the application. When this happens we are forced to restart the Mendix service on the application server. Some investigation uncovered certain update queries causing database locks. Deleting the locks on the database don't allow the application to be responsive again. The mendix service needs to be restarted every time this happens. Is this a known issue? Is there a way to handle this? Is there anything else we can investigate to identify the root cause of this issue? Is it possible that this is not related to database process locks? Please let me know if you require more information. This is rather urgent as it impacts a production environment and is causing a lot of unnecessary down time. I have copied three of the queries that have caused locks below but the locks are not limited to these three. declare @p1 int set @p1=20 exec sp_prepexec @p1 output,N'@P0 int',N'DELETE FROM [leadmanagement$statuslog_lead] WHERE [leadmanagement$statuslogid] = @P0 ',668180 select @p1 and (@P0 datetime2,@P1 int,@P2 int)UPDATE [audittrail$audittrailsuperclass] SET [changeddate] = @P0, [system$changedby] = @P1 WHERE [id] = @P2 and (@P0 varchar(8000),@P1 varchar(8000),@P2 datetime2,@P3 nvarchar(4000),@P4 varchar(8000),@P5 bit,@P6 varchar(8000),@P7 nvarchar(4000),@P8 int,@P9 datetime2,@P10 varchar(8000))INSERT INTO [csrworkflow$task] ([system$owner], [system$changedby], [changeddate], [status], [duedate], [duenow], [note], [debug], [taskpriority], [createddate], [alertduestatus]) VALUES (@P0, @P1, @P2, @P3, @P4, @P5, @P6, @P7, @P8, @P9, @P10) select SCOPE_IDENTITY() AS GENERATED_KEYS Thanks Sam
2 answers

Database locks in general are caused by concurrent write activities from different transactions (users, web services, scheduled events).

They usually become a problem when write activities take a long time.

So my first place to look would be long running write activities (inserts, updates and deletes).

If you are in the position you could rule out certain causes by for example turning of ALL scheduled events.


Were you able to solve this problem?

We are experiencing the same issues also on our Audit Trail updates.