Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

In our install script, which installs several solutions together, we found that solutions were occasionally failing to deploy with the following error in the ULS log:

System.Data.SqlClient.SqlException: Violation of PRIMARY KEY constraint 'PK_Classes'. Cannot insert duplicate key in object 'dbo.Classes'.

This occurs with both Powershell and stsadm.

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

We had logic that was calling Install-SPSolution twice on different solutions (same behavior observed with stsadm), and then logic for waiting for the deployment to complete. In rare instances, what happened, is that both solutions were attempting to acquire the deployment lock before either thread got the lock; one thread would succeed and one would fail with the Primary Key exception.

So the log would look like:

Solution Deployment : Acquiring deployment job lock for server ... solutionA.wsp  
Solution Deployment : Acquiring deployment job lock for server ... solutionB.wsp  
Solution Deployment : Successfull ACQUIRED deployment job lock for server ... solutionA.wsp 
System.Data.SqlClient.SqlException: Violation of PRIMARY KEY constraint 'PK_Classes'. Cannot insert duplicate key in object 'dbo.Classes'.

Instead of:

Solution Deployment : Acquiring deployment job lock for server ... solutionA.wsp  
Solution Deployment : Successfull ACQUIRED deployment job lock for server ... solutionA.wsp 
Solution Deployment : Acquiring deployment job lock for server ... solutionB.wsp

(followed by solutionB being denied and waiting for solutionA to finish)

The solution is to install one solution, wait for it to complete, then install another. There's some samples of how to wait using the JobExists property on the solution here: Detecting Solution Deploying Status. It's not really any slower to do it this way (no more than your waiting interval), because behind the scenes SharePoint runs one job and then the other anyways when the locks are properly acquired.

share|improve this answer
    
I thought if I posted the question and answer together it would already be marked as answered. Posting because I thought it might help others who run into the same or similar SQL errors (look for threading issues!) –  lgaud Jul 11 '13 at 20:02
    
Won't the sptimer job allow you to programatically wait for one job to be finished before starting another? –  BlueBird Jul 11 '13 at 20:29
    
@lguad Nope, you have to come back after a certain time period and mark it as the answer. –  Robert Kaucher Jul 11 '13 at 22:19
    
@BlueBird I added some information about how to wait to the answer. I posted this because the error you do get in this scenario in that 1% of the time where the locks don't work properly is very obscure :) –  lgaud Jul 12 '13 at 11:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.