DataContext.SubmitChanges 超时并带有奇怪的堆栈跟踪

Question

我的为期两年的大型项目刚刚在两周前上线。虽然我们遇到了正常的启动问题，但它非常成功，除了一个奇怪的错误已经出现。

这个故事已经被改变了；实际项目与电影票无关。

我们的网站允许电影院的员工打印电影票。一旦他们决定了要打印的内容，他们就会转到打印票据网页并单击“打印”。这会将一批数据发送到电影票打印机，几秒钟后，用户的票证打印机开始打印票。

我们对门票进行编号，并希望确保不使用重复的编号。执行此操作的代码如下所示：

using (TicketContext context = new TicketContext(ConnectionString)) {

    // call a stored proc that allocates a group of tickets with fancy transaction stuff

    var result = context.GetNextTicketGroup(tickets.Count).FirstOrDefault();
    if (result == null || !result.Column1.HasValue || result.Column1.Value == -1)
        return "There was an error allocating ticket numbers";
    int ticketNumber = result.Column1.Value;

    // Put the ticket numbers in the ticket objects
    int i;
    for (i = 0; i < ticketCount; i++) {
        tickets[i].TicketNumber = ticketNumber + i;
    }
    for (i = 0; i < ticketCount; i++) {
        // Convert the ticket object that we've been working with into 
        // a record that is the kind we have in the database and 
        // put that into the database.  CreateTicket() doesn't do any 
        // database stuff directly.
        DBTicket newticket = CreateTicket(ticket[i]); 
        context.Tickets.InsertOnSubmit(newticket);
    }
    // Each ticket is tied to an Issuance ID - Get a list of IssuanceIDs from the
    // list of tickets and mark them as printed
    var IDs = items.Select(id => id.IssuanceID).Distinct();
    foreach (Guid g in IDs) {
        var Issuance = context.TicketIssuances.Where(ti => ti.ID == g).FirstOrDefault();
        if(Issuance != null) {
            Issuance.Printed = true;
        }
    }

    // Submit the changes to the database
    context.SubmitChanges();

    // Send the printers to the ticket printer via a web service
    using (TicketService.TicketSoapClient ssc = new TicketService.TicketSoapClient()) {
        var a = tickets.ToArray();
        if (ssc.PrintTickets(a) == false)
            return "Error printing.";
    }
}   // LINE 392

现在，不寻常的部分是 context.SubmitChanges() 超时，但堆栈跟踪如下所示：

 [...]  
 at System.Data.Linq.ChangeDirector.StandardChangeDirector.Insert(TrackedObject item)
 at System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode failureMode)
 at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
 at Portal.Tickets.PrintTickets.PrintTicketList(List`1 items) in d:\Source\PrintTickets.aspx.cs:line 392
 at Portal.Tickets.PrintTickets.btnPrintTickets_Click(Object sender, EventArgs e) in d:\Source\PrintTickets.aspx.cs:line 236
 at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
 at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

我在上面的代码中调用了第 392 行；请注意，此时数据上下文超出了范围，远在超时应该发生之后。

这些都是小工作，如果没有某种僵局或其他原因，肯定不会超时；我们一次只将数十条记录放入数据库，并且服务器不会承受过多的负载。我们 99% 以上的作业提交都顺利完成，只有一小部分遇到了这个错误，但是当他们这样做时，其中有几个人在几分钟之内就遇到了这个错误。除了奇怪的堆栈跟踪之外，我倾向于完全归咎于数据库服务器。有什么见解吗？

Answer 1

如果超时，这看起来像是一个导致死锁的竞争条件。尝试增加一些整数值作为票证的唯一 ID 而不是简单地使用 GUID 的动机是什么？ LINQ-to-SQL 确实通过设置 DataContext.Log 属性提供了一些有限的日志记录，但我不知道这在您的生产场景中有多有用/可行。