1

I'm successfully using ServiceStack (SS) solely for session handling for a standard ASP.NET website. So that means no SS web services or authentication. Currently, I'm only able to use it if I initialize an AppHostBase derived class and add ServiceStackHttpHandlerFactory to Web.config.

This means that effectively I'm running stuff that is intended to host a SS service, even though I'm not using one. Is there anyway to avoid this, or is the session handling reliant on the AppHost running? From the source it looks like that latter, but I would like to check please.

Co7e
  • 1,008
  • 10
  • 17
  • Why not just use [ASP.NET sessions](http://msdn.microsoft.com/en-us/library/ms178581(VS.100).aspx)? – Mike Sep 19 '13 at 16:18
  • Mainly because we've been getting thread agility issues as described [here](http://stackoverflow.com/questions/17064380/what-happens-in-beginprocessrequest/17073158#17073158) and [here](http://stackoverflow.com/questions/3629709/i-just-discovered-why-all-asp-net-websites-are-slow-and-i-am-trying-to-work-out). SS's optimistic session handling suits our application. We're also using SS very successfully in a more traditional way on another application and will probably start using more of its features within the website mentioned in this question. – Co7e Sep 20 '13 at 09:31

1 Answers1

3

I apologize for going with the 'it depends answer' but I'm not quite sure how you're using the ServiceStack Session in your current ASP.NET website and what 'pieces' of the SS Session you need. In my mind the SS Session is just a blob of data stored in a cache with a unique id for a user's (browser or client) requests/responses.

If your request for the Session data goes through the ServiceStack Pipeline then I'm pretty confident that you would need an AppHost instance to get this to work. The main reason being that SS needs to add a Request Filter and set the ss-id, ss-pid session cookies. These cookies are the 'Key' for storing/retrieving the Session data.

If your requests don't go through the ServiceStack Pipeline I would imagine you write your own code that uses an instance of ICacheClient and provide your own Key (perhaps using the ASP.NET SessionID? as a key) and an instance of AuthUserSession (or really any Class/Type). Below is an extremely naive example

Set up the Cache for the application to use
if you using something like Redis or other 'Stand Alone Server' cache you wouldn't make it a static variable on the application.

public class Global : HttpApplication
{
    public static ICacheClient CacheClient; 
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        AuthConfig.RegisterOpenAuth();
        RouteConfig.RegisterRoutes(RouteTable.Routes);

        CacheClient = new MemoryCacheClient();
    }
} 

Access the Session from a code-behind page...

public partial class _Default : Page
{

    protected void Page_Load(object sender, EventArgs e)
    {
        var session = GetOrCreateSession();
    }

    private AuthUserSession GetOrCreateSession()
    {
        var session = Global.CacheClient.Get<AuthUserSession>(this.Session.SessionID);

        if (session != null)
            return session;

        var authUserSession = new AuthUserSession();
        Global.CacheClient.Set(this.Session.SessionID, authUserSession);
        return authUserSession;
    }
}
paaschpa
  • 4,816
  • 11
  • 15
  • Thanks, this is correct. You can't use SS's session handling without initiating an AppHostBase derived class. The code contains various references to EndPointHost (in the Cookies class for example), which are dependent upon it. Any solution would involve rewriting a lot of the code, so much so that you would effectively being creating your own session handling. @paaschpa's suggested solution makes sense, but of course you aren't using SS's session handling then, just its caching. We've opted to just initiate the AppHostBase derived class for now as the overhead is practically nothing. – Co7e Sep 27 '13 at 14:44