SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just wanted to see what the consensus on this one is…

If you make a call to the OM to return a SP object e.g. SPListItemCollection, and then want to cache the results (to improve subsequent performance and usage of the object/data) would you "unpack" the contents of the collection/object into a custom class and cache that or just cache the native SP object?

I’m not sure if there is any reason to introduce the overhead of a custom class etc?

share|improve this question
up vote 4 down vote accepted

Not sure if it's a good idea to cache native SP objects. Think about memory usage (all that internal COM stuff) and lifecycle management of the objects (when do you dispose your SPSites/SPWebs?)

If it's list data you want to cache, why not cache a DataTable?

share|improve this answer

Agree with Jaap - caching of objects returned from SharePoint should generally be avoided, since even if that particular object doesn't implement IDisposable (and thus require disposal by you), it's likely that other objects which do will be referenced.

In addition to memory pressures mentioned by Jaap I think you could run into other problems. Here's what I think will happen if you cache certain SP objects:

  • Explicit disposal is not happening so the GC will dispose them for you
  • At some point later you retrieve the object from the cache, attempt to use it and an exception will occur, effectively saying "attempted to use a previously disposed object"

OR if you're very lucky it's one of the objects which the SharePoint API manages heavily and a new instance will be spun up for you - this will be recorded in ULS logs. This is purely a safety mechanism, isn't implemented everywhere, and since a new object is ultimately spun up there's absolutely no gain from the caching.

My recommendation would be to always seek to cache disconnected objects.

share|improve this answer
Thanks Jaap and Chris. Seems you agree with Jaap I marked his as the answer (a answer split would be helpful!). I wondered whether any SP objects could cause further DB round trips (& therefore negate any benefits of caching) and your thinking seems to indicate that might happen. – Nick Hadlee Mar 17 '10 at 5:00

I would lean more towards the custom class option in the case of wanting to store list item data.

As Chris pointed out, by reading your data into a custom class you have removed the chance of referencing a disposable object (ie ParentWeb) at a later time.

Also, if you are caching on a per-user basis (something you would want to do if your items have the probability of having unique permissions), a simple class would probably consume less memory that an SPListItem object.

share|improve this answer
Thats really good info to have pointed out. I think the quality of the 2010 documentation is fantastic. Cheers Paul – Nick Hadlee Mar 17 '10 at 19:49
The article you referred to suggests that caching SPListItemCollections isnt bad practice but the best practice is to cache the DataTable as Jaap suggests. In both instances they suggest using a lock. Thanks again – Nick Hadlee Mar 17 '10 at 19:56

Typically you should just cache the native SharePoint object unless there is a specific need to create a custom class (such as needing to extend that class with custom methods or actions for example).

share|improve this answer
Thanks Rob. Thats what I have normally done but it "occurred" to me that maybe there was a better way. I always like to recheck assumptions every now and then – Nick Hadlee Mar 16 '10 at 20:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.