IIS 6 Session timeout issue (Web.Config cannot solve all timeout problems)

We were receiving calls from a client saying that they kept being kicked out of one of our systems quite regularly usually after 20-30 mins of inactivity.

We got to work and firstly checked the usual suspects, the web.config file sessionState timeout and the forms timeout for forms authentication. Both of those were set to > 2 hours so it couldn’t have been those.

I debugged on my local machine and found that everything was working fine and the session was being killed after the correct timeout stated in the web.config file. It seemed it was a server configuration issue. Now our situation is complex as we share authentication across multiple systems including legacy PHP code, So i tried all of those configs, to no avail.

At last eureka! It seems the actual application pool was being recycled after 20 mins of inactivity. This was an application pool being used by only 1 client so was not being hit as often as most. If your having similar problems check your application pool’s session time out values and application recycle values.. Ours was set to 20 mins of inactivity which I believe is the default.

Advertisements

SaaS Multitenant ASP.NET 4.0 – Step 1 Introduction

Introduction

This is the first in what I have planned to be a series of posts all about moving your application(s) to a multi-tenant architecture.

I have noticed that there really isn’t enough being done in the way of frameworks and tutorials in the area of multitenancy, especially using .NET and the Entity Framework. Please learn with me as I tackle the many problems I am facing right now moving our suite of products to a more Saas friendly environment.

Software as a service

I’m sure most have heard the buzz phrase “Software as a service (SaaS)”, I won’t go into too many details here about the model itself, a quick google search will find many articles that cover the concept much better than I could here. Basically it can be very cost effective for ISV’s as it pushes configuration over customisation, low running costs, subscription paid services and it fits perfectly in the cloud. I really like the concept as a developer because it means less custom coding for client specific functionality, makes it much easier to manage versions of code (when clients are on the same branch) and it is extendable by its nature so gives room for evolutions of the software’s purpose.

This series is aimed at the actual implementation of a multi-tenant architecture using .NET 4.0 technologies. This essentially means allowing multiple clients (or tenants) to run on the same codebase with their own custom fields, themes, workflows and other features.

When implementing this architecure some problems will be faced such as:

  • How many databases will we need? 1 per client, 1 database for all clients?, etc.
  • How will we manage custom client fields that need to persisted to that database?
  • How will the UI change to reflect those extra fields?
  • How do we manage custom reporting?
  • Where will we place business logic that will change per client?
  • How do we inject extra business logic and validation for client specific decisions?
  • How will we manage custom client workflows?
  • How do offer particular features to only those clients who have paid for them?
  • If a client wants to change a theme to suit their intranet’s theme can we allow for this?
  • How will we handle users, login/logout methods, roles and permissions so that the security aspect of the system is abstracted well enough to be easily defined per client? How will the our user’s manage their security roles and users?
  • Is it worth doing all this work, or should we just make client changes on their own versions of code? (Works for a certain threshold of clients to resources and for systems that don’t need much in the way of customisation)
  • How do we build this architecture in the most elegant way. And when I say elegant I mean without needing 20 layers of abstraction

If your still with me you’ll see that multi-tenancy poses quite a few questions and is not something that can be done overnight. The benefits are that you get to manage only one branch of code and can have quite a few clients on there happy without needing to do some serious customisation of the product and without needing to manage a seperate version of code for each client (headache!).

The cons are obviously the upfront cost in time and effort. I’m am facing this problem now and hopefully this guide and the relevant source will help those looking to solve this problem using .NET technolgies.

So stay with me and lets work through this headache together. Up next will be our data access layer and database design.

Cheers

EF 4.1 DbContext Issue : Manually opening and closing the database connection

As I’m sure many of you are aware the Entity Framework will create and close database connections automatically when needed. This is great most of the time, however when we want to manually configure the connection for performance or to perform a list of actions within a transaction we don’t want the entity framework to automatically close our connection.

I’ve found an issue where I’m trying to manually manage my DbContext connection and the DbContext API does not want to let me.
(I’m using Sql Server 2005 and am trying to avoid transaction promotion to the DLC which means I want to do all of my queries on the same connection).

In ObjectContext land, when I call ObjectContext.Connection.Open() I am manually opening the connection and the documentation states on MSDN that this connection will NOT be closed until I call the Close() method or dispose of the context.

It seems calling DbContext.Database.Connection.Open() does not give the same results. When called I watch the context close and reopen for each query. Below is the code that I am trying to write that presents the problem.

DbContext version:


            dbContext.Database.Connection.Open();
            using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
            {
                  // perform a list of queries
                 // the connection will close
                 scope.Complete();
                 dbContext.Database.Connection.Close();
            }

ObjectContext version:


            (dbContext as IObjectContextAdapter).ObjectContext.Connection.Open();
            using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
            {
                  // perform a list of queries
                 // The connection will not close!
                 scope.Complete();
                 (dbContext as IObjectContextAdapter).ObjectContext.Connection.Close();
            }

So the fix for now is to get the ObjectContext from your DbContext. But can someone explain what the difference is and is this by design?