Hey folks,

We upgraded two of our production boxes to .NET 4.5 over the weekend. Immediately after that upgrade, we started receiving numerous errors like the following:

ex message: Scope can't be disposed. Most likely it is bound to a different thread.
Stack Trace: at Xtensive.Core.Scope`1.Dispose() at 
             Xtensive.Core.DisposableSet.b__0(IDisposable d) at 
             Xtensive.Core.ExceptionAggregator.Execute[T](Action`1 action, T argument)

It seemed to be primarily on our Web Forms pages, and specifically on posts. We're using 4.6.2 and the 4.6.2 Web extension. Any ideas on what may be causing this? We had to downgrade to .NET 4.0 in order to resolve the issue, and since we have some code that relies on the async/await functionality in 4.5 in feature branches, we need a resolution to this ASAP. Thanks.

Edit:

It seems like it's happening intermittently on any page where the code initiates a Response.Redirect(). So, for example, with:

<asp:Button ID="btnOrderSearch" runat="server" Text="Search for Order" />

...and the following method:

Protected Sub btnOrderSearch_Click(sender As Object, e As System.EventArgs) Handles btnOrderSearch.Click
    Dim searchby As String = ddlOrderSearch.SelectedValue
    Dim searchfor As String = txtOrderSearchFor.Text
    If searchby <> "" And searchfor <> "" Then
        Response.Redirect("Admin_OrderSearch.aspx?searchtype=" & searchby & "&orderID=" & searchfor)
    End If
End Sub

...I can almost 100% of the time reproduce it. The same goes for any other pages in which we have Response.Redirect going on. There doesn't even necessarily need to be any DataObjects code anywhere on the page that's posting back, but there always is DataObjects code on the page we're redirecting to.

asked Sep 03 '13 at 10:58

GigMastersTech's gravatar image

GigMastersTech
27111115

edited Sep 18 '13 at 10:19


2 Answers:

Hello GigMastersTech,

I think doing async invocations do not preseve HttpContext, which is used by SessionManager to store and resolve Session objects. There is no universal solution to work around this. Async methods typically heavily switch execution threads. I think the best solution is to pass session explicitly where it's required. DataObjects.Net supports explicit sessions in the various API since 4.4

answered Sep 05 '13 at 03:51

Denis%20Krjuchkov's gravatar image

Denis Krjuchkov
179325

We're not doing any async invocations. Are you saying that the framework between 4 and 4.5 changed to use async invocations on web forms submissions?

(Sep 06 '13 at 12:19) GigMastersTech GigMastersTech's gravatar image

I'm not sure. As I've already said SessionManager is very simply and relies on HttpContext available everywhere. Could you show some code where the exception is thrown? If you don't want to post it here use the support@dataobjects.net e-mail.

(Sep 10 '13 at 03:39) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

See edit posted to my original question.

(Sep 18 '13 at 10:19) GigMastersTech GigMastersTech's gravatar image

Thanks for the information. This definitely needs our thorough investigation.

(Sep 18 '13 at 10:26) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Have you looked into this any further?

(Nov 09 '13 at 18:07) Dancho Dancho's gravatar image

Hello Alex, we're currently investigating this. Sorry for delay.

(Nov 11 '13 at 08:35) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Still investigating?

(Dec 02 '13 at 21:03) Dancho Dancho's gravatar image

....so not investigating? Love the attention to detail here, guys.

(Dec 10 '13 at 13:09) Dancho Dancho's gravatar image

Hello Alex, we did not manage to reproduce this problem. If you could create an example project that demostrates the problem this would definitely help us in resolving your issue.

(Dec 10 '13 at 14:03) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

We're getting it all over the freaking place now. WebAPI calls on .NET 4, WebForms calls on .NET 4.5, MVC4.... it's pretty much everywhere.

(Dec 10 '13 at 14:17) Dancho Dancho's gravatar image

Hi,

I'm suspecting that behavior of Response.Redirect implementation might have been changed. Devs say that in earlier versions of framework the call threw ThreadAbortException and now throws it no more. Another point is that there is a recommended way of calling Response.Redirect method:

Response.Redirect(url, false);
Context.ApplicationInstance.CompleteRequest();

Could you please try this pattern and tell me whether the issue is gone? If not, I'd appreciate a sample that reproduces the problem or access to your solution (if it is possible). We tried to reproduce the issue in our environment but failed.

Thanks in advance.

answered Dec 11 '13 at 22:51

Dmitri%20Maximov's gravatar image

Dmitri Maximov
22111211

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×8
×2
×1
×1

Asked: Sep 03 '13 at 10:58

Seen: 3,131 times

Last updated: Dec 11 '13 at 22:51

powered by OSQA