views:

298

answers:

4

I've seen developers use two approaches when they are done with a session object.

1) Session.Remove(key)

2) Session(key) = nothing

What is the better approach of the two above? Does Session.Remove dispose the object stored automatically?

Does the second approach depend on the garbage collector to actually free up the memory?

EDIT: Thanks for the responses, guys. Seems like Session.Remove is the correct way to go. However, if Session.Remove does not guarantee the disposal of object, then what is the best way to dispose the object stored in session when we do not need it further?

Thanks.

+1  A: 

I'd prefer Session.Remove(key) because it removes memory used for the key in the session dictionary as well; with the second approach the reference to the value is disassociated, however the key is still present in the Session dictionary.

Neither of the approaches will call dispose on the object, that has to be done manually.

Both approaches depend on the garbage collector to free up memory, In the first approach the memory for the key object can become available for collection as well. Also remember that just because you removed a reference to the object from the session dictionary does not mean that it is not referenced anywhere else in your app.

Sijin
+5  A: 

If you set the object to null or nothing, the key still exists in the Session even though the value is null.

This behaviour is the same as any other dictionary type classes in the CLR.

If you want to remove an object completely from the Session, you should use the Session.Remove("key") method. It wont throw an exception if the key is not present in the Session.

Ed B
A: 

Session.Remove(key) is generally speaking, the safer way to go if you want to actually remove the object from cache. Bear in mind, that if you use inproc session management, then the object doesn't get serialized so there's a chance it could be getting referenced by something other than the session manager, therefore the garbage collector won't necessarily clean it up. If you use out of proc session management, then the object is serialized and as a result, there is no "in memory" representation of the object and therefore the garbage collector doesn't really need to "clean it up"

Setting the Session(key) = nothing doesn't actually remove the key from session, it just sets it to null. Again, the same rules around garbage collection apply.

lomaxx
A: 

The actual logic that gets executed in either case is determined by the implementation of the type that is implementing the ISessionStateItemCollection interface located in the System.Web.SessionState namespace. The concrete type implementing that interface is determined by the configured session store provider.

The built-in providers (In-Proc, State Server, and SQL Server) all utilize the SessionStateItemCollection class located in the System.Web.SessionState namespace, so this is the implementation that will be used in the great majority of cases, since most people don't implement a custom session store provider.

As others have pointed out, if the value is really being removed from session because it doesn't need to be referenced anymore, at least for the time being, then you should probably call the Remove method just for the sake of cleaning up the internal storage mechanisms of the Session object. Neither of the methods explicitly dispose of the object that was previously stored with that key.

Dr. Wily's Apprentice