We are using Vault 3.1.6 and Cruise Control 1.0, when cruise control is checking for modifications we sometimes get this error:
System.Data.SqlClient.SqlException: Transaction (Process ID 89) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at VaultServiceSQL.VaultSqlSystem.LoginUser(VaultSqlConn conn, String strLogin, String strDbHashPwd, Guid& gSession) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
what causes this?
What would cause a deadlock
Moderator: SourceGear
The short answer:
There's nothing that you, as a user, can do to prevent this, but it's not a cause for concern, either. CruiseControl will poll again for changes and get them. You can make this less annoying by turning off "publishExceptions" in your ccnet.config, so you won't be notified when this error occurs. The downside to this fix is that labels (if you have CC.NET configured to get source and apply labels) will not be removed in the event of a failed build.
The slightly longer answer:
We started actively working with the CruiseControl project just a week or two before they release 1.0. Unfortunately that was too late to get our changes in. There are significant improvements that (almost certainly) will be included in CruiseControl.NET's next release that anyone running Vault 3.1.6 (or later) will be able to take advantage of.
The deadlock issue you're seeing is usually precipitated by a large number of projects in CruiseControl. Particularly when you first start the CC.NET server, it polls for the changes to all those projects essentially simultaneously, and the server sometimes deadlocks, which in this context essentially just means: try again in half a second or so.
In the forthcoming CC.NET changes I mentioned, the polling for changes is significantly faster, which should reduce the occurence of deadlocks. The labelling issue I mentioned, when turning off CC.NET's "publishExceptions" is also fixed.
There's nothing that you, as a user, can do to prevent this, but it's not a cause for concern, either. CruiseControl will poll again for changes and get them. You can make this less annoying by turning off "publishExceptions" in your ccnet.config, so you won't be notified when this error occurs. The downside to this fix is that labels (if you have CC.NET configured to get source and apply labels) will not be removed in the event of a failed build.
The slightly longer answer:
We started actively working with the CruiseControl project just a week or two before they release 1.0. Unfortunately that was too late to get our changes in. There are significant improvements that (almost certainly) will be included in CruiseControl.NET's next release that anyone running Vault 3.1.6 (or later) will be able to take advantage of.
The deadlock issue you're seeing is usually precipitated by a large number of projects in CruiseControl. Particularly when you first start the CC.NET server, it polls for the changes to all those projects essentially simultaneously, and the server sometimes deadlocks, which in this context essentially just means: try again in half a second or so.
In the forthcoming CC.NET changes I mentioned, the polling for changes is significantly faster, which should reduce the occurence of deadlocks. The labelling issue I mentioned, when turning off CC.NET's "publishExceptions" is also fixed.
Ian Olsen
SourceGear
SourceGear