Question

I’ve the following doubt. I’ve a page “MyPage” and i’ve declared few dictionary objects in the page class.

My doubt is

1. If i declare the dictionary as a private non-static object i’m not able to use it across the functions in that page class (the object is getting nulled)
2. But if i declare the dictionary to be static i’m able to across the object across the functions. But will that object be same across all the users who have opened the page right now (guessing that each user will have an instance of the page in turn has an instance for the page class and static variables of a class are invariable across all the instances of the class)

Is my understanding right? How to declare the object to be available across all the functions within the page class and unique for each instance of the page (user).

Update1

Okie, i find that the initialization of the dictionary object in the page class is done in a different thread (WCF Duplex callback). But in the main page thread the dictionary object is still remaining as null (uninitialized). Any ideas?

Update2

Marshalling – useful by any chance?

Update3

In reply to John-

Thanks for your reply. The problem i’m facing now is to pass the data from the WCF callback class at the client side(which will be invoked in a separate thread) to the asp.net page. So how can i do that? View state may help me to persist the data across requests. But when the callback is invoked by the server notifying for a change how should i pass the changes (data) to the UI thread (asp.net page)?

Answer 1

Don’t do things like this.

If you need to maintain data between pages, use Session state. That’s what it’s for. You should remember that you get a new instance of your page class on every request. Do not use statics to keep changing data around for subsequent requests. You will probably get into trouble with multiple requests updating the data at the same time.

---

You can’t do things like this with ASP.NET!

You seem to be treating this as though it were a desktop program – as though your class instance and all state will still be there for you next time you execute a method on the page. That’s not true – when the request is complete, your page will be Disposed. Nothing about the page will remain valid.

In particular, if the callback doesn’t happen before the request ends, then the callback method had better not reference anything having to do with the request, like your page. That’s because the callback might fire after the request is already over! The state is corrupt or worse.

Unless you are going to have the page wait for the callback, you’d really better not use them in your pages. Instead, create a separate Windows Service or something and have it issue the requests and await the callback. The page can then use Ajax or something to ask if the request is complete, and to get the response once complete.

---

If you think you heard me say to call back to an ASP.NET page, then you misunderstood.

Create a Windows Service. Your Windows Service will host a WCF service that the ASP.NET application will talk to. The WCF Service will keep track of things like who’s joined a chat, who’s typing, etc.

The web application cannot be notified when something interesting happens. Instead, the web application will have to poll the WCF service, asking if anything interesting has happened. When something happens, the WCF service will pass the “something” back to the ASP.NET application (or possibly, back to the page, called by AJAX).

I misspoke earlier. You simply cannot use a callback contract at all in this situation. It’s not like the web pages are like a desktop application, one per user, waiting to be notified. They’re more like a desktop application where, when the user makes a request, you take his PC and give him a new one just like it, before the response arrives.