In a previous post, I raised an issue regarding a SQL stored procedure not being created upon the creation of the ASP.NET Session State Service Application. This stored procedure takes care of the deletion of the expired sessions. When we check our timer jobs, we also see we have a definition which is called “State Service Delete Expired Sessions”. This obviously is connected to the regular State Service, but let’s take a closer look on how this timer job works.
Before we go deeper into the fundamentals, you’ll need a tool, which is free, called ILSpy. It’s a .NET decompiler, so if you already have one, you’re good to go. When you’ve downloaded ILSpy, extract it somewhere and you can fire it up. The main screen looks like this:
Select any open libraries and remove them. This gives us a clean start:
Next, we’re gonna look at the timer job itself. We need to know in which library it’s located so we can decompile it with ILSpy. Leave ILSpy open and fire up the SharePoint 2010 Management Shell. Type in the following command:
Get-SPTimerJob | ?{$_.Title -eq "State Service Delete Expired Sessions"} | Select TypeName
This will give you the following output:
Microsoft.Office.Server.Administration.StateServiceExpiredSessionJobDefinition
Great! Let’s go back to ILSpy and open the Microsoft.Office.Server library from the GAC:
Next select the Microsoft.Office.Server library and click “Open”:
Expand the library to view all the namespaces. Expand the Administration namespace and scroll down until you find the StateServiceExpiredSessionJobDefinition class. When you decompile this class, you can expand any of the methods and properties. We’re interested in the Execute method, cause that’s what fires when the timer job is executed:
So all it does is call the static DeleteExpiredSessions(current) method on the StateSqlSession class. When we go deeper and click on the method, we can see what happens behind the scene:
Seems that all that happens is call a SQL Stored Procedure “proc_DeleteExpiredItems” from this Timer Job:
Deep diving into Timer Jobs can give you a lot of insight into the engine of SharePoint. The following PowerShell command lists all the Titles and TypeNames from the registered Timer Job Definitions so you can go even deeper:
Get-SPTimerJob | Select Title, TypeName | fl
You’ll notice that health rule jobs are registered differently. Getting their TypeName is also a bit different. You have to use the local SPHealthRulesList:
[Microsoft.SharePoint.Administration.Health.SPHealthRulesList]::Local.Items | Select Title, @{ Label="HealthRuleType"; Expression= { $_["HealthRuleType"] } } | fl