KNOWN ISSUE: Express database deadlocks cause job scheduling to fail for all computers being imaged
Article ID: 176753
Updated On:
Products
Issue/Introduction
Deployment Solution is used to build Windows* XP SP2 computers from a Sysprep image. After the image is downloaded on the client a number of tasks are chained to automate the build.
The current issue is that too often events stop (they no longer start after the previous event complete succesfully). They are scheduled but do not start.
When this scheduling error occur we can see on the event logs (for the server):
At this point in time, all computers that are being built (and at various stages in the build process) stop after they complete the current task succesfully (the next task is scheduled but never started).
To solve this problem, the Deployment Solution services are restarted but this is not a viable solution.
SQL dead-locks logs are attached as per article 34145.
Cause
[02/26/08 16:04:12.417] f54-CDBException caught in GetJobStatusInfo: Transaction (Process ID 66) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
[02/26/08 16:04:12.417] f54-CRxCtrlServer::CloseDatabaseConnections - Entered.
[02/26/08 16:04:12.433] f34-CRxCtrlServer::UpdateEventStatus - Exited.
[02/26/08 16:04:12.433] f34-Unknown exception was caught in CRxCtrlServer::BrokerSessionRequest
[02/26/08 16:04:12.433] f34-CRxCtrlServer::BrokerSessionRequest - Exited.
[02/26/08 16:04:12.433] f34-BrokerSessionRequest () returned FALSE...
[02/26/08 16:04:12.433] f34-Found another request in the receive buffer.
[02/26/08 16:04:12.433] f34-Request from 10.254.194.122 (Socket (7732), ID: 5001143) (1978 bytes):
Request=EventStatus
ID=5001143
Schedule-ID=100008727
Task-Sequence-ID=0
Status=SECTION 'Set Regional and Language - Chinese Traditional' => SKIPPED Code de rerour = 0.
Level=1
Time-Offset=0
Status-Module=
Result=Success
[02/26/08 16:04:12.433] f34-Brokering request...
The following extracts shows the activity of thread f34. Note that the broker session request in red is not exited immediately (here starts the deadlock):
[02/26/08 15:45:01.438] f34-Socket: Received on socket (3664) - 2920 char received.
[02/26/08 15:45:01.438] f34-Socket: Received on socket (3664) - 2034 char received.
[02/26/08 15:45:01.438] f34-Request from 10.254.225.126 (Socket (3664), ID: 0) (4954 bytes):
[02/26/08 15:45:01.438] f34-Brokering request...
[02/26/08 15:45:01.438] f34-CRxCtrlServer::BrokerSessionRequest - Entered.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::BrokerSmartUpdate - Entered.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::GetBasicSessionInfo - Entered.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::GetBasicSessionInfo - Exited.
[02/26/08 15:45:01.438] f34-CRxDatabase::IsSmartUpdateOK - Entered.
[02/26/08 15:45:01.438] f34-CRxDatabase::IsSmartUpdateOK - Exited.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::BrokerSmartUpdate - Exited.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::ProcessUpdateOrAddComputer - Entered.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::GetBasicSessionInfo - Entered.
[02/26/08 15:45:01.438] f34-CRxCtrlServer::GetBasicSessionInfo - Exited.
[02/26/08 15:45:01.438] f34-BrokerSessionRequest: Checking rejection list...
[02/26/08 15:45:01.438] f34-BrokerSessionRequest: Parsing fields of request...
[02/26/08 15:45:01.438] f34-CRxDatabase::FindComputer (LPCTSTR pszMacAddr) - Entered.
[02/26/08 15:45:01.438] f34-CRxDatabase::GetField - Entered.
[02/26/08 15:45:01.454] f34-CRxDatabase::GetField - Exited.
But instead it is terminated after the deadlock is resolved (as shown in the first log extract).
Resolution
The issue returned in DS 6.9. A fix for this issue will be provided as part of DS 6.9 sp1 due out in the fourth quarter of 2008.
Applies To
A Deployment Solution 6.5 environment was migrated to Deployment Solution 6.8 SP2. Due to a large number of scheduling errors, the new stored procedure was implemented for the DS event_schedule updates.
Attachments
Feedback
