Пренасочване на страница, докато все още се изпълнява бавно Linq.DataContext.SubmitChanges() в ASP.NET

За интранет приложение имам функция за запазване на уеб страница, която може да доведе до значително действие върху няколко таблици на база данни. Използвам Linq2SQL и около 20 секунди неактивен браузър се поглъщат от 3 отделни Linq.DataContext.SubmitChanges() извиквания. Тези извиквания се случват точно в края на кода, извикан от обратното изпращане на SaveButton.

Искам действителната работа, необходима за натрупване на тези промени в базата данни, да се извърши в рамките на действието на бутона за запазване. Въпреки това, като се има предвид, че не са открити проблеми или конфликти, бих искал да пренасоча потребителя към друга страница веднага след това (за да не се налага да се взират в екрана, правейки нещо, което не могат да спрат. След това, докато потребителят продължава, бих искал обадете се на всички SubmitChanges().

Идеален работен процес:

void btnSaveClick() 
{
    CalculateChangeSetProcedure
    Redirect somewhere...
    SubmitChangesProcedure
}

Така че моят проблем е Response.Redirect(..., true) просто ще изключи нещата. Има ли някакъв начин да направя това с ASP.NET процедури или ще трябва да го направя async в друга нишка?


person sh54    schedule 29.04.2011    source източник
comment
Изглежда, че няма да променя събитието на бутона, а вместо това работя върху промяната на кода за изпращане на DB, за да използвам SqlBulkCopy възможно най-прозрачно вместо това. Фантастична връзка: Внедряване на SqlBulkCopy в Linq към Sql. Това напълно трансформира времето ми за вмъкване.   -  person sh54    schedule 29.04.2011
comment
Можете да публикувате това като отговор и да го приемете, ако е проработило за вас. Така че въпросът е приключен.   -  person Thea    schedule 01.05.2011


Отговори (2)


Ако се опитвате да изпратите малко количество данни, времето на неактивност, което имате, не е нормално. Първото нещо, което можете да направите, е да проверите функцията за изпращане и да видите, че има нещо, което можете да оптимизирате. Например, ако изпращате 50 реда и извиквате SubmitChanges след всеки от тях, това може значително да забави нещата. Решението в този случай е да подготвите цялата дата и да я изпратите наведнъж.

Друг вариант е да се обадите на услуга, която изпраща промените вместо вас. По този начин запазването ще се извърши асинхронно и няма да пречи на потребителя. След като услугата приключи, можете да получите някакъв прост изскачащ прозорец на jQuery или нещо друго, което да информира потребителя, че запазването е завършено, ако това е важно.

person Thea    schedule 29.04.2011
comment
Това е голямо количество данни. 20 секунди на db сървъра за разработка са резултат от няколко хиляди вмъквания в множество таблици в 3 бази данни. Старият код, който оптимизирах, използваше за изпращане на много малки парчета, за които предупреждавате. Обмислям вашия отделен подход към уеб услугата... - person sh54; 29.04.2011
comment
Вижте тази статия weblogs.asp.net/stevewellens/archive/2010/04/02/ - person Thea; 29.04.2011
comment
ако вмъкнатите данни са твърде големи, тогава трябва да внимавате, че процесът ASP.net ще бъде убит, когато времето за изчакване изтече. Едно възможно решение за това всъщност е извикването не на уеб услуга или друга ASP.NET нишка, а извикването на услуга на Windows. По този начин нишката няма да има таймаут. - person Thea; 29.04.2011

Стартирайте отделна фонова нишка за повикване SubmitChanges(), преди да извършите пренасочването.

e.g.

void btnSaveClick() 
{    
      CalculateChangeSetProcedure
      ThreadPool.QueueUserWorkItem(new WaitCallback(this.SubmitTheStuff), null);
      Redirect somewhere..
}
private void SubmitTheStuff(object obj)
{
      SubmitChangesProcedure
}    
person Hauzi    schedule 29.04.2011
comment
Опитах го, но не мога да спра Linq.DataContext.SubmitChanges() да се взривява, когато го насоча към друга нишка. - person sh54; 29.04.2011
comment
да Но поне браузърът трябва да пренасочва, докато SubmitChanges() върши работата си. Какво имаш предвид с взривяване? Памет? - person Hauzi; 29.04.2011