Systems design question: DB connection management in load-balanced n-tier

Question

I'm wondering about the best approach to designing a DB connection manager for a load-balanced n-tier system.

Classic n-tier looks like this:

Client -> BusinessServer -> DBServer

A load-balancing solution as I see it would then look like this:

                    +--> ...            +--+
                    +--> BusinessServer +--+--> SessionServer --+
Client -> Gateway --+--> BusinessServer +--|                    +--> DBServer
                    +--> BusinessServer +--+--------------------+
                    +--> ...            +--+

As pictured, the business server component is being load-balanced via multiple instances, and a hardware gateway is distributing the load among them.

Session server probably needs to be situated outside the load-balancing array, because it manages state, which mustn't be duplicated.

Barring any major errors in design so far, what is the best way to implement DB connection management?

I've come up with a couple of options, but there may be others I'm not aware of:

1. Introduce a new Broker component between the DBServer and the other components and let it handle the DB connections.

   • The upside is that all the connections can be managed from a single point, which is very convenient.
   • The downside is that now there is an additional "single point of failure" in the system. Other components must go through it for every request that involves DB in some way, which also makes this a bottleneck.
     
     

2. Move the DB connection management into BusinessServer and SessionServer components and let each handle its own DB connections.

   • The upside is that there is no additional "single point of failure" or bottleneck components.
   • The downside is that there is also no control over possible conflicts and deadlocks apart from what DBServer itself can provide.

What else can be done?

FWIW: Technology is .NET, but none of the vendor-specific stacks are used (e.g. no WCF, MSMQ or the like).

Answer 1

In the end, I went with a design that is hybrid of the two I mentioned in the question. I've made the Broker and SessionServer into dynamic components, which can then each be configured to run either in-proc with BusinessServer or out-of-proc, thus covering all conceivable combinations.

In essence I've chosen to put in a bit more work to make the system customizable so I'll be able determine the best approach case by case.