2

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?

Improve this question

4 Answers 4

Reset to default
4

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?

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splistitemcollection.getdatatable.aspx

Improve this answer
4

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.

Improve this answer
1
  • 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
    Commented Mar 17, 2010 at 5:00
1

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.

http://msdn.microsoft.com/en-us/library/ee558270(office.14).aspx

Improve this answer
2
  • Thats really good info to have pointed out. I think the quality of the 2010 documentation is fantastic. Cheers Paul
    – Nick Hadlee
    Commented Mar 17, 2010 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
    Commented Mar 17, 2010 at 19:56
0

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).

Improve this answer
1
  • 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
    Commented Mar 16, 2010 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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