Improving XPO scalability with ASP.NET

The current version of Developer Express XPO has a Session object that handles one connection to the database together with an object cache for that session. Technically, the Session is a pivotal point in the XPO architecture, all object handling requests go through a Session object.

Recently it came to my attention that some people regard it as a great problem that the Session object is tightly bound to a database connection. By default, this is a direct association: you can create more than one session object in an application, which will result in more than one database connection. If there are many clients, implemented with XPO, accessing a central database, there’ll be as many database connections as there are clients. Not necessarily a completely unusual situation, and in the domain of client/server and multi tier applications, respectively, there are numerous ways to implement things differently, if needed. Personally, I tend to prefer application server designs these days, where things obviously scale differently in this regard.

The real problem is most clearly visible when thinking about ASP.NET applications. To make XPO data available to an ASP.NET application, there are three general approaches, as detailed nicely in this article from the XPO online help: (a) one global XPO session, (b) one XPO session per ASP.NET session and (c) one XPO session per request. There isn’t much to say (apart from what’s already said on that page) about (a) and (c), but (b) is of interest: while it seems to be the perfect solution in terms of manageability (certainly better than (a)), it has its drawbacks where performance is concerned because the multiple Session objects can’t share an object cache and, much worse, because the lifetime of an XPO session also defines the lifetime of a database connection.

Of course it would be nice if the session had a mechanism that would simply drop the current connection every time it’s finished using it. With connection pooling, as employed by default by the SqlClient, the overhead for getting a new connection would be small but resources could be used much more efficiently when database connections would only be acquired if (and for the time they are) needed. This functionality is missing in the current XPO version. It could be relatively easy to make the necessary changes in the XPO source code, I’m still looking into this.

Until that point, there’s a simple solution that works nicely in many cases: When the database connection that’s used for a session is closed, that connection is returned to the connection pool and can be reused elsewhere. Interesting enough, XPO already contains the code that will re-establish the connection before it’s needed the next time. The important thing is that you must use a line like this:

// close the inner connection

This is not the same thing as mySession.Disconnect();! You’ll need to add a line like that in all places where you know that your work with the session has been done for the moment. It’s very well possible, for example, to access the session to build a collection of objects, make sure they’re loaded (e.g. by accessing one of them), close the connection and continue to work with the objects! There’s nothing much that can go wrong here because XPO will always re-establish the connection if it’s needed after all.

In a simple test I made, this approach worked nicely in the ASP.NET scenario I was talking about. I restricted the connection pool to two connections and I was able to access the application with five clients nevertheless, because connections were reused from the pool by all five Session objects.

I hope this will prove helpful for someone!

7 Comments on Improving XPO scalability with ASP.NET

  1. Interesting thought. I too am using XPO as my persistence layer in an ASP.NET application. I’ve had a few problemswith running out of connections in the connection pool, and I’m was wondering if it had something to do with XPO keepingahold of the connections too long. I am using sort of a pattern that keeps an XPO session in the ASP.NET cache for asmall amount of time (allows only for 2 minutes of inactivity) and is kept unique per connected user (similar to having anit in a session with a 2 minute timeout) I am going to try forcing XPO to close the connection when it is done with it, and see if that fixes the problem. BTW, have you noticed any problems like I am describing (XPO hogging up the connection pool)?Thanks… good blog.


  2. Sure, this can happen as long as you don’t break the “1 Session = 1 DB Connection” paradigm. It’s obviously a good idea to restrict the lifetime of an XPO session on the ASP.NET level, but if there’s a lot of concurrency the connection might still run empty very quickly.


  3. thanks your blog. can you send a Sample for me ? i just now use,need help .in that way ,I was very lucky.


  4. can you send a example which use multiple session? thanks a lot


  5. This stuff has all changed very much in the newest XPO release… you should have a look at some allround explanations in this post to the new DX community blog and also at the newsgroups, where a lot of this stuff has been discussed since the release of XPO 6.1.


  6. how would the multiple sessions be handled if they from a database like mysql?


  7. forever šŸ™‚


Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s