Continuing in my series of articles showing the many ways in which we can store configuration data for your SharePoint applications, this time we look at how to use SPPersistedObject to achieve this.
Don’t forget to check out part 1 of the series in which we find out how SPWebConfigModification can be used for persisting application configuration in SharePoint 2010.
Persistence Using SPPersistedObject
SPPersistedObjects let you store hierarchical configuration data for your application in SharePoint. An SPPersistedObject is a class you subclass. You can then add fields (not properties) to your class, attribute them with [Persisted], and SharePoint will serialise the object to Xml in the SharePoint Configuration database.
- [GuidAttribute(“8AC7737A-8A57-4DD9-A782-B0B3F4595884”)]
- public class JoelsConfigSettings : SPPersistedObject
- {
- public JoelsConfigSettings()
- {
- }
- public JoelsConfigSettings(string name, SPPersistedObject parent)
- : base(name, parent)
- {
- }
- public JoelsConfigSettings(string name, SPPersistedObject parent, Guid id)
- : base(name, parent, id)
- {
- }
- [Persisted]
- public string Value1;
- [Persisted]
- public int Value2;
- }
The above code creates a class with two fields (string Value1 and int Value2) which can be persisted for the current Web Application with the following code:
- SPSite s = SPContext.Current.Site;
- JoelsConfigSettings settings = new JoelsConfigSettings(“JoelsSettingsKey”, s.WebApplication, s.ID);
- settings.Value1 = “Joels Value 1”;
- settings.Value2 = 2;
- settings.Update();
We can later retrieve – and optionally delete – the settings by calling GetChild<> on the WebApplication object.
- SPSite s = SPContext.Current.Site;
- JoelsConfigSettings settings = s.WebApplication.GetChild<JoelsConfigSettings>(“JoelsSettingsKey”);
- string value1 = settings.Value1;
- int value2 = settings.Value2;
- // optionally delete our settings
- settings.Delete();
- // but proper removal requires unprovisioning and uncaching too
- settings.Unprovision();
- settings.Uncache();
As an alternative to storing at the Web Application level, you can use a Farm object instead.
Advantages
You configuration data is stored in the SharePoint Configuration database. This means it will be backed up along with the rest of your SharePoint data – assuming you perform SharePoint backups, of course. 
Your data is also safe from prying eyes as there is no UI to edit these settings.
Disadvantages
There is no built in user interface to manage SPPersistedObjects. This is both a good and a bad thing: you have to provide your own way of editing the values you wish to store. To read and write these values you also need to impersonate a user, such as a Farm Administrator, with read and write privileges on the Config database (SPSecurity.RunWithElevatedPriviliges() won’t help here!). There are some reports of SPPersistedObject use corrupting the Hierarchical Object Store; it’s unclear whether this is due to incorrect usage or something more flaky. Reading the comments, one of our readers has suggested this corruption happens for them if they use obfuscated assemblies. (Many thanks, Joe!)
Proceed with caution, and thoroughly test your code first on a virtual, scratch, SharePoint farm.
Here’s a how-to that expands on this post and coveres some of the common gotchas of working with SPPersistedObject and the hierarchical object store
http://www.chaholl.com/archive/2011/01/30/the-skinny-on-sppersistedobject-and-the-hierarchical-object-store-in.aspx
Hi. I think elevated privileges is not enough to write the configuration database. With elevated privileges you will use the the web application app pool’s identitty, which has only read permission to the config db by default (putobject sp execute right is not granted). Of course admin user (which runs the central admin should have read and write permissions).
One thing more,
HOS (hierarchical object store) can be easily corrupted if you obfuscate your assembly, since the persisted property names will be obfuscated! This leads to a corrupt state. Check the config cache. You will see all the persisted variable names will be a simple space.
From my experience :)
That’s a very good point. I didn’t mean to imply SPSecurity.RunWithElevatedPriviliges() would work. It won’t. As you suggest, you need to impersonate an account that has read/write permissions to the Config DB – such as a Farm Administrator. I will adjust the wording in the blog post accordingly.
Thanks for the feedback!
joel
How to use custom timer job scheduling in SharePoint 2010?
The scheduling information like min,hours should be read from custom list in SharePoint site and using feature receiver we need to pull the information from list and update the timer job definition.
How Can we read the site url and custom list url and send it to the feature receiver for updating the timer job definition?
adding to my comment using SharePoint 2010 The Hierarchical Object Store for custom timer job scheduling
You can give it privilleges to write to config database by overriding HasAdditionalUpdateAccess method of SPPersistedObject like this:
protected override bool HasAdditionalUpdateAccess()
{
return true;
}
At least it worked for me.