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行;请注意，在超时应该发生之后，它正处于datacontext超出范围的位置。

这些小工作当然不会因为出现某种僵局而超时;我们一次只将数十条记录放入数据库，服务器不会过载。 99％以上的工作提交都很顺利，只有很小一部分可以达到这个错误，但是当他们这样做时，其中几个人会在几分钟之内完成它。除了奇怪的堆栈跟踪之外，我倾向于完全责怪数据库服务器。有什么见解吗？

Answer 1

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

DataContext.SubmitChanges使用奇怪的堆栈跟踪超时

1 个答案: