No lock and distinct conditions in query expression

Hi Folks,

Whenever i tried using query expression for retrieve multiple operations, came to know some interesting facts which exists and hence would like to share with you all.

As you already know Query expression was used when dealing with a little complex query, lets see this in action

Basic Query Expression Example


// Query using ConditionExpression and FilterExpression
ConditionExpression condition1 = new ConditionExpression();
condition1.AttributeName = "lastname";
condition1.Operator = ConditionOperator.Equal;
condition1.Values.Add("Brown");
FilterExpression filter1 = new FilterExpression();
filter1.Conditions.Add(condition1);
QueryExpression query = new QueryExpression("contact");
query.ColumnSet.AddColumns("firstname", "lastname");
query.Criteria.AddFilter(filter1); query.NoLock = true;//Condition to prevent occurrence of deadlocks, distinct was used to retrieve unique columnsets in the query
EntityCollection result1 = _serviceProxy.RetrieveMultiple(query);

The benefit of setting NoLock to true is that it allows you to keep the system from issuing locks against the entities in your queries; this increases concurrency and performance because the database engine does not have to maintain the shared locks involved. The downside is that, because no locks are issued against the records being read, some “dirty” or uncommitted data could potentially be read. A “dirty” read is one in which the data being read is involved in a transaction from another connection. If that transaction rolls back its work, the data read from the query using NoLock will have read uncommitted data. This type of read makes processing inconsistent and can lead to problems. The risk of having “dirty” data is something to consider, especially in high database transaction environments.

Reference: https://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.query.queryexpression.aspx 

https://mscrmmindfire.wordpress.com/2013/11/26/avoiding-deadlock-in-plugins/

http://www.resultondemand.nl/support/sdk/f5d2195b-8cae-49d6-a493-6f8b92e7f54e.htm

Hope this helps some one…

Cheers,

PMDY

Plugin Execute Method- should be stateless|A deep insight

Hi All,

I was writing Plugins from long time, but this time i had a just a deeper insight into the exact code which we write and came to know that the Plugin’s execute method should be stateless as this code would cached and the same object would be called multiple times based on requirement to improve the CRM Performance.

CELEDON Partners had a great post about this from an architectural point of view can be found.

Hope this helps some one…

Cheers,

PMDY

User Impersonation in Plugins, Workflow and Dialogs

Recently I was searching for knowledge base regarding impersonation in Plugins and here were some of my findings.

Impersonation in Plugins

The following grid shows the various user identities present for Plugins. ‘Triggering User’ refers to the logged in user who saves the record in Dynamics CRM and triggers a Plugin to fire. It’s also worth noting that offline plugins will fire once offline as shown and then *again* on the server.

Impersonation in Dialogs and Workflows

The following grid shows the various user identities present for Workflows and Dialogs. The interesting thing here is the difference between Parent and Child Automatic Workflows.

Hope it helps someone!!!

PMDY