Microsoft Dynamics CRM (Archived)

prevent plugin to run multiple instances on the same time

(0) Share

Report

Posted on by Tobias Koller

hi,

I have a plugin which is registered with several steps on multiple entities.

My entities (renamed to keep it simple) are: "A" 1:n "B" 1:n "C"

the plugin is registered for updates in "A", "B" and "C" and also registered for create in "B" and "C".

so everytime someone changed anything inside the records of "A","B" or "C" the plugin gets executed.

this is no problem when I edit records over the web-form f.e.

But when I use the bulkedit-funktion to change a value in multiple-records about 50% or more of the records failed to update because of a "generic SQL error".

This error occurs inside the plugin when it tries to update the entity above or even try to get records over the webservice ( I guess It can appear in every use of the webservies)...

So my question is: Is there a way to lock the plugin that it will never runs multiple-instances at the same time (bulkedit)?

I tried a

private static Object _lockObject = new Object();

lock(_lockObject)

{

//here is my code....

}

but It didn't work. I ran in a endless loop I think ;)

thanks a lot

Tobias

*This post is locked for comments

I have the same question (0)

All responses (13)

Answers (0)

SyedHussain 1,820 on at

Like (0)

Report

There are two options here; one you can trap for depth (context.depth) or two add a bit field in the form to have the plugin execute only if the bit value is true. Since you only need the plugin to fire when a user is on the form, then the latter is the best approach. I always add a bit field as an extra safety measure on forms so that I know plugins won't fire inadvertently.

Was this reply helpful? Yes No
Peter72 1,815 on at

Like (0)

Report

I am running into the same issue and do not have a solution currently. Syed's suggestion is not suitable in our case, because bulk edit is used in our case. Does anyone have a suggestion to avoid the errors? The "Generic SQL errors" are DB-Locks in our case, because each plugin-execution reads the same set of records.

Any help is appreciated!

Peter

Was this reply helpful? Yes No
Suggested answer

Hosk on at

Like (0)

Report

Do you need the plugins to run for the bulk import.

is it possible you could disable some of the plugins temporarily using the plugin registration tool, whilst you import the data in the bulk import.

If not a suitable option, maybe you could import a particular in the bulk import and then add a line in the plugins to check for this and if it's present don't run the normal code. import sequence number is often a good field to use and set when importing data into CRM.

adding this code to check for the field wouldn't have any effect on normal usage.

Was this reply helpful? Yes No
Peter72 1,815 on at

Like (0)

Report

Hi Ben, thanks for your reply. We need the plugin to run while bulk EDIT, not bulk import.

We have a custom activity entity in a subgrid. The user selects a few of them and push a custom button which updates these records (writing a command into a hidden field) via Jscript. The plugin fires on that update. This plugin has to check if similar records exist and executes some logic. This check (retrieve similar records) fails due to the DB-Lock.

Hope this epxlains the issue we are facing.

Peter

Was this reply helpful? Yes No
Tobias Koller on at

Like (0)

Report

thanks for your answers.

but unfortunatelly none of the answers could help me.

the customer uses the bulkedit in the webclient to change many fieldvalues at one (sometimes about 250 records).

this will start the plugin several times (in this example 250 times).

I Need to insert a lock or something like that to make sure that only one plugin-instance runs at once ...

Was this reply helpful? Yes No
Peter72 1,815 on at

Like (0)

Report

It is exactly what we need too, Tobias. Hope someone can help us here.

What we have done so far was enabling the Read Committed Snapshot Isolation (TCSI) on the database. This has reduced the count of DB-Locks, but sometimes the issue still occurs.

Was this reply helpful? Yes No
Tobias Koller on at

Like (0)

Report

hi Peter,

in your case maybe a lock(){} would help you like I posted it inside my first question.

in our case another problem is, that the plugin also call updates which will start another instance of the plugin (for the above entities).

so when they update via bulkedit about 250 record, about 250 (i guess) instances of the plugin will start and they will start the plugin again (because of changes inside the plugin)..

very complicated (this is the most complicate plugin i've ever written :) )

Was this reply helpful? Yes No
Peter72 1,815 on at

Like (0)

Report

Is the plugin updating the same fields as the user updates? If not, it may be a solution to filter the attributes on which the plugin fires

Was this reply helpful? Yes No
Suggested answer

Hosk on at

Like (0)

Report

There are a few things you can do all mentioned in the replies

enabling the Read Committed Snapshot Isolation (TCSI) on the database.

this basically turns off table locking when you are only reading data on tables

You could also either put in a db lock or you could put in a random thread sleep which would stagger the updating a little bit.

The other alternative you could do, is possibly tigger an update plugin on a record hosting the subgrid and then write some code which goes through all the items selected in a loop so there would be no locking. I'm not sure a plugin would be able to read the subgrid (and which records were ticked) so you would need some javascript to save the guids into a text field and use that in your plugin.

Was this reply helpful? Yes No
Peter72 1,815 on at

Like (0)

Report

Another thought: You may check if the current update is coming from a user, or from the plugin itself. Stop execution if it comes from the plugin itself. Maybe context.depth (Syed's suggestion) can help here.

Was this reply helpful? Yes No