NoLock – to be set or not

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

NoLock – what is that?

NoLock is a QueryExpression property used to specify how a RetrieveMultiple request will behave. Take a look at MS documentation since I’m not used to rewrite someone else’s posts, CRM upgrade features and MS limited documentation. Long story short: NoLock property sets to TRUE looks at database record lock and waits for previous database transaction operation(s) to finish. When sets to FALSE it executes retrieve operation immediately.

Which value to set ?

In most scenarios the value is being set by default when using either QueryExpression or FetchExpression. I like to explicitly declare it’s value in order to inform other team members that this is not a coincident that this property is set to current value. It is important not only for internal CRM plugins but also external, 3rd parties applications and integration processes.


TRUE – will not decrease the performance since it will not block the transactions, may lead to a ‘dirty data reads’

FALSE – may affect the performance but it depends on implemented plugins architecture, safe from data consistency perspective


It is tricky

Oh yes, it is. Till now I have noticed 2 situations:

  • so called dirty reads. Mainly in legacy code. Since RetrieveMultiple request is not waiting for other database operations to finish it might occur that data I am retrieving will be updated couple of milliseconds later by other plugin. In this scenario attribute(s) value may have old value.
  • plugin pipeline execution. Let’s imagine a situation that we have EntityA and EntityB which is a child of A created automatically via sync plugin when A is being created. We have also some integration plugins which communicates with NServiceBus and publish events (every create operation) for external application to be consumed. Then 3rd application is using some predefined repositories to get the CRM entities and maps (AutoMapper) is to DTOs for internal uses. We cannot change the NserviceBus integration plugins order.
    The basic flow is: manual creation of EntityA triggers a plugin to automatically create a child record, EntityB. After that another set of plugins (integration ones) are being called to publish bus event.
    For this particular example the integration plugins execution pipeline is: Integration plugin EntityA on create starts, Integration plugin EntityB on create starts, Integration plugin EntityB finishes, Integration plugin EntityB finishes.
    Why NoLock property is so important here? 3rd party application is reading the bus in order how the events has been received. Because the event for EntityB cames first it will be processed first. To create DTO CRM will be queried – but the EntityA is still in transaction (of course if the application is quick enough, and you know – Murphy’s Laws are working :)) so it might lead to a situation that EntityA will not exists yet.


In my private opinion NoLock is being used wisely and consciously everyday by developers that really understand the plugin execution pipeline and occasionally by those who are looking for a bug 🙂


P.S. If you found this post useful please rate it/ share it.

Have an own opinion?