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
mySession.Connection.Close();
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 ran, 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!