[.NET] CallContext veilig of niet?

[Tony L]

Ik zit al een tijd te kijken naar de CallContext maar ik krijg tegenstrijdige informatie. De 1 zegt dat je er niets moet storen als je met ASP.NET werkt terwijl de ander zegt dat het goed kan. Ik zou graag met de CallContext werken omdat je dan niet afhankelijk bent van het HttpContext object. Voor Windows applicaties zou dat dan inhouden dat je een reference moet leggen naar de System.Web.dll terwijl je die in de meeste gevallen helemaal niet nodig hebt.

Nu probeer ik de boel uit te testen maar naar mijn mening kan je dus veilig objecten saven in de CallContext. Ik heb de volgende setup: Ik heb 2 pagina's, een fast page en een slow page. De slow page bevat een timeout zodat ik de fast page kan blijven refreshen om threading issues te genereren. Ik heb de thread pool van ASP.NET verlaagd naar maximaal 2 worker threads en minimaal 2 worker threads om de kans op threading issues nog groter te maken.

C#:

public partial class Fast : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)        
    {
        Debug.WriteLine(String.Format("-Fast- Default name: \"{0}\"", Storage.Name));
        Debug.Flush();
        Storage.Name = "Fast";
        Debug.WriteLine(String.Format("-Fast- Getting name: \"{0}\"", Storage.Name));
        Debug.Flush();            
    }
}

public partial class Slow : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Debug.WriteLine(String.Format("-Slow- Default name: \"{0}\"", Storage.Name));
        Debug.Flush();
        Storage.Name = "Slow";
        Debug.WriteLine(String.Format("-Slow- After set: \"{0}\"", Storage.Name));
        Debug.Flush();
        Thread.Sleep(5000);
        Debug.WriteLine(String.Format("-Slow- After timeout: \"{0}\"", Storage.Name));
        Debug.Flush();            
    }
}

public class Storage
{
    private const string KEY_NAME = "Name";

    public static string Name
    {
        get { return CallContext.GetData(KEY_NAME) as string; }
        set { CallContext.SetData(KEY_NAME, value); }
    }
}

De output doet precies wat ik verwacht, zelfs als ik als een gek loop te refreshen.

code:

-Fast- Default name: ""
-Fast- Getting name: "Fast"
-Slow- Default name: ""
-Slow- After set: "Slow"
-Fast- Default name: ""
-Fast- Getting name: "Fast"
-Fast- Default name: ""
-Fast- Getting name: "Fast"
-Slow- After timeout: "Slow"

Zijn de bronnen die ik heb gebruikt fout of zit er iets niet goed in mijn test / zie ik iets over het hoofd?

Enkele bronnen:
http://piers7.blogspot.co...c-callcontext-and_02.html
http://integralpath.blogs...5/03/threadstatic_fu.html
http://forum.springframew...572&highlight=CallContext

[ Voor 0% gewijzigd door een moderator op 07-06-2007 14:29 . Reden: code=c#. Syntax highlighting FTW \0/ ]

[whoami]

Als je met ASP.NET werkt, werk je best met HttpContext.

Je kan natuurlijk abstraheren wat je precies gebruikt; maak ergens een class die je zelf gebruikt om je 'state' in op te slaan, en die class beslist of de CallContext of de HttpContext moet gebruikt worden.
(Als HttpContext.Current null is, gebruik dan CallContext, anders HttpContext)

In the previous edition of this article, NHibernate's ISession was stored and retrieved solely via System.Runtime.Remoting.Messaging.CallContext. Although perfectly fine for WinForms and NUnit tests, this is a very bad idea for ASP.NET as the ISession may be "lost" under load.

[ Voor 63% gewijzigd door whoami op 07-06-2007 14:40 ]

[Tony L]

Ik weet dat de HttpContext gebruikt dient te worden maar ik zou graag willen begrijpen waarom de CallContext niet geschikt is (ik wil dit kunnen beargumenteren). En aangezien meer dan de helft van de info die ik kan vinden totaal niet uitlegt waarom je de CallContext niet mag gebruiken schiet dat ook niet echt op. Heb jij een idee?

[whoami]

Die artikelen geven toch al aan wat het probleem kan zijn ? Ik begrijp dat je het probleem nog niet hebt kunnen reproduceren.

Nog een linkje:
klik

[Not Pingu]

Misschien heeft het te maken met het feit dat in het geval van ASP.NET threads gemanaged worden door de onderliggende applicatieserver (IIS e.d.)?

[edit]Lezen

[ Voor 5% gewijzigd door Not Pingu op 07-06-2007 15:00 ]

[Tony L]

whoami schreef op donderdag 07 juni 2007 @ 14:58:
Die artikelen geven toch al aan wat het probleem kan zijn ? Ik begrijp dat je het probleem nog niet hebt kunnen reproduceren.

Nog een linkje:
klik

Ik denk dat ik goed begrijp waarom het mogelijk niet zou kunnen werken en wil dit inderdaad kunnen reproduceren. Als ik het goed begrijp dan kunnen de events binnen de applicatie op andere threads gedraaid worden. In het slechtste geval zal dan elke event door een andere thread afgevangen worden, waardoor je de data niet in de CallContext kan opslaan. De reden dat die persoon in de link die jij gaf een probleem heeft komt omdat er een nieuwe request plaatst vind als hij op de knop gedrukt heeft. De CallContext is daar dan dus al verdwenen en daarom is de waarde niet terug te vinden.

[gorgi_19]

* gorgi_19 vond http://piers7.blogspot.co...c-callcontext-and_02.html wel een mooie uitleg.

HttpContext is gebonden aan een request. CallContext is gebonden aan een thread. Een request is niet per definitie gekoppeld aan een thread Vaak wordt deze gekoppeld, maar met hoge load kan dit verschillen.

Een beschrijving wat er achter de schermen gebeurd:

quote: http://support.microsoft....anscripts%2Fwct060503.asp

The next thing to consider is the high load (slide 7), which basically means that the I/O threads are mostly busy processing other requests. So at some point ASP.NET decides that there are too many I/O threads processing other requests: "I don't want to process any more requests on I/O threads, because I'm running out." These I/O threads are used internally by ASP.NET for other purposes, other than just processing your requests — for sending responses back and other things, it uses I/O threads.

It just takes the request and it queues it up in this internal queue object within the ASP.NET runtime. Then, after that's queued up, the I/O thread will ask for a worker thread, and then the I/O thread will be returned to its pool. The I/O thread is not processing any requests at this point. It only queues it up and it puts in a request for a worker thread. The way that happens is just like you would do in your code with Threadpool.QueueUserWorkItem.

The ThreadPool object gets that request to the QueueUserWorkItem call, and whenever there's a worker thread available, the worker thread will be used to call into the callback function. And that's the ASP.NET code. So ASP.NET will have that worker thread process the request. It will take it into the ASP.NET runtime, just as the I/O thread would have under low load. It's the same scenario from there. Eventually, at the end of that chain, your code is invoked.

En hier zit ook het gehele probleem. Het gaat in de meeste gevallen goed (> 99%), maar je mag er niet 100% op vertrouwen dat de data beschikbaar is. Condities wanneer het fout kan gaan zijn bijvoorbeeld een hoge load. In dat opzicht verbaasd het me ook niet dat je de boel niet hebt kunnen reproduceren.

[ Voor 88% gewijzigd door gorgi_19 op 07-06-2007 17:58 ]

[whoami]

offtopic:
even de topic titel van C# naar .NET veranderd, aangezien dit niet C# specifiek is

[Tony L]

Hartelijk dank voor je reactie! Ik kan het inderdaad niet reproduceren maar ik denk dat ik maar moet aannemen dat wat er staat ook daadwerkelijk zo is. Thanks!

gorgi_19 schreef op donderdag 07 juni 2007 @ 17:47:
* gorgi_19 vond http://piers7.blogspot.co...c-callcontext-and_02.html wel een mooie uitleg.

HttpContext is gebonden aan een request. CallContext is gebonden aan een thread. Een request is niet per definitie gekoppeld aan een thread Vaak wordt deze gekoppeld, maar met hoge load kan dit verschillen.

Een beschrijving wat er achter de schermen gebeurd:

[...]


En hier zit ook het gehele probleem. Het gaat in de meeste gevallen goed (> 99%), maar je mag er niet 100% op vertrouwen dat de data beschikbaar is. Condities wanneer het fout kan gaan zijn bijvoorbeeld een hoge load. In dat opzicht verbaasd het me ook niet dat je de boel niet hebt kunnen reproduceren.