I presented on Sandboxed Solutions at the Perth SharePoint User Group on Thursday night alongside Sezai Komur (he did Client OM). I went through the standard bits and pieces on Sandboxed Solutions (see references for more detailed info):
- why
- benefits
- what you can do
- what you can't do
- resource points and quotas
- about the Services that monitor them and execute them
- how to debug them
I then showed a demo of all this, highlighting a Sandboxed Solution actually breaching the resource quota within a Site Collection that I had developed and deployed locally. I adjusted the quota to illustrate that 10 exceptions (1 resource point quota) would breach the quota by refreshing a Web Part with an exception 10 times.
One thing I did notice was the wording when the Sandboxed Solution did breach:
""
Punish them all
This immediately concerned me…what if I had multiple Sandboxed Solutions deployed in that Site Collection? Surely if it is monitoring the resource points for each Sandboxed Solution…it will simply disable the one that breaches? The quota limit actually accounts for the sum of all of the resource points accumulated by ALL Sandboxed Solutions in the Site Collection. So if between them they breach the quota, ALL of them are disabled.
Really?
In a typical scenario, it'll be one rogue Sandboxed Solution that will be chewing through the resource points causing the quota to be breached within a day. SharePoint will simply switch off ALL Sandboxed Solutions without punishing the individual one. I think this will not be the expected result by most people out there. There was some shrugs in the UG audience around it doing this.
Benefits
The benefit of Sandboxed Solutions in this scenario is that it won't implicate other Site Collections, even if those Site collections have the same WSP uploaded to it. This can often be useful, when a certain branch of code fails based on the configuration of the Site Collection e.g. a list may have too many list items and queries time out etc. To extend on this it won't affect other Web Applications either which is a compelling reason for Multi-Tenancy.
It does allow Site Administrators to monitor individual Site Collections to see what ones are chewing through resources and hopefully catch them before they reach their quota. That way not affecting the nicely written WSPs that are not chewing through it ;-) There are plenty of PowerShell scripts to help in this instance.
The Reason
@pndrw (Paul Andrew, Senior Technical Product Manager, Microsoft) was kind enough to respond to my query on this and the explanation behind this is because a site collection is owned by one person/team/tenant. If it wasn't architected to switch them all off, a Site Collection owner could simply upload the same bad WSP multiple times with different GUIDs and use more resources that way.
Will people use this?
I think once people realise that it's focus is to prevent affecting other Site Collections and not isolating/sandboxing individual WSPs. I guess this is really the wording of "Sandboxed Solutions", maybe should have been "Sandboxed Site Collections".
References