views:

29

answers:

1

Hi,

I'm developing a web service with ASP.NET, is not an .asmx or WCF, it's a custom one, so I'm working with the Http classes (context, request, response, etc..). Session is disabled. I'm working with my own handler and module.

I'd like to keep a object alive and accessible for the time the connection is alive. I mean, a request enters, I assign a DbCommand to it and that connection will use that command as long is doing things, when that connection is ended, the object should be disposed.

I've thought, that I can add it to my IPrincipal implementation, then when the connection is authenticated in the module and the user retrieved, I can add that DbCommand to the IPrincipal, so I can retrieve it from wherever I want in the code, and after in the module EndRequest event, I can dispose it, but I don't know if there is a better approach to do this.

What do you think?

cheers

A: 

It is somewhat dependent on your WCF configuration.

I suggest you read this, as it may give you some insight into the direction you want to take. http://msdn.microsoft.com/en-us/magazine/cc163590.aspx

How will your client be connecting to the service?

You can also use a singleton pattern on the service (so it and its data persists across 'sessions') and store the data in the service object itself on a per user basis.

Krisc
It's not WCF. The client connects with a simple WebRequest. What I want to avoid is keep a collection for this, because then I have to synchronize the access and add/delete. I just want to stick a object to the HttpConext or HttpRequest for example, but I don't know where. Cheers.
vtortola
Ah, I misread the question! I apologize.Your best bet (IMHO) would be the cache then. You don't need to use a collection in the cache to store your objects and can rely on user specific data as a key to retrieve their objects.
Krisc
But with cache will persist between connections, won't it? I want to keep it just for the connection time.
vtortola
Yes. There isn't a way (aside from capturing a window close event and sending a request to the server) to know that a client has closed their window. Even capturing a window close event isn't perfect since the computer could randomly be turned off or the browser task ended. Or simply the browser may not send requests for closed pages.
Krisc
This is not a web page, is a web service :DI think I'll do it as I planned before, maybe is not so bad idea :P
vtortola
Right, but it is still attempting to persist states across requests using the default HTTP classes?My point is that regardless of how this thing is served, it needs to persist the objects in some sort of repository or cache. That it cannot/should not depend on the client sending an "I'm done!" request.
Krisc