mod_dbd: Saying technically

Hello,
Two previous articles—“Introduction to database functionality of Helicon Ape” and “How to connect mod_dbd with various databases” were aimed at every customer and they are enough if you don’t want to deepen into this matter. But in case you’re such a guy who wants to learn the internals of mod_dbd—please feel comfortable. In this article you’ll find what you need.
One little note: the text below requires basic knowledge of .NET Framework.

What’s inside

As you may guess mod_dbd completely relies on ADO.NET. This is a most common way for .NET applications. For more information on ADO.NET please follow the references below:

• Overview of ADO.NET
• ADO.NET in Wikipedia

In other words mod_dbd loads any database provider through ADO.NET. Here is a scheme which illustrates the idea:

Database providers for Microsoft SQL Server and Oracle as well as ODBC and OLEDB interfaces were included in .NET Framework, so we support them natively and you don’t need to install additional software. However any other ADO.NET compatible provider may be used because mod_dbd is able to load external .NET assemblies. We’ll talk about that a little later. Now let’s take a look on connection pooling.

Connection pooling

mod_dbd in Apache supports connection pooling for threaded platforms. It has its own implementation with the help of APR library. We have considered to implement something similar but in a different way. ADO.NET kindly provides developers with connection pooling features, so mod_dbd uses nothing more. As opposed to Apache guys we have the fixed platform—Windows, so that’s pretty natural to use ADO.NET internal features.
Below we presume that you’re familiar with the connection pooling idea. If you’re not, please read the following great article by Dino Esposito: “The Connections of ADO.NET Connection Pooling”.

In ADO.NET connection pooling works very transparently. It’s configured through special connection string arguments. The following idea lays in the basis—connections with equal connection strings are put into one connection pool unless this breaks the connection pool rules.

So generally mod_dbd directs its directives values to particular connection string arguments. They are as follows:

• DBDPersist → Pooling
• DBDExptime → Connection Lifetime
• DBDMax → Max Pool Size
• DBDMin → Min Pool Size

Loading external providers

As we've mentioned before, mod_dbd is capable of loading ADO.NET providers from external .NET assemblies. Let’s consider one example which is probably better than dumb bare strings.
We’re going to use PostgreSQL connector. After downloading and extracting you will see Npgsql.dll assembly within bin folder. This assembly should be copied into GAC (C:\windows\assembly) or put near Helicon.Ape.dll. We’ve copied ours to GAC and opened the assembly’s properties:

The properties highlighted in red should be specified in DBDriver directive as follows:

DBDriver adonet "Npgsql.NpgsqlConnection, Npgsql, 
  Version=2.0.8.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7"

We also have to specify a connection string, so here is the final configuration:

DBDriver adonet "Npgsql.NpgsqlConnection, Npgsql, 
  Version=2.0.8.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7" 
DBDParams "Data Source=server;Initial Catalog=database;
  User ID=user;Password=password"

Quite easy, isn’t it? You are probably wondering whether this hinders the performance. Well, assembly loading isn’t a quick process, however mod_dbd does it only when configuration file changes. Usually it’s rare operation and you shouldn't worry about performance slump.

Summary

We’ve explained the internal organization of mod_dbd, described connection pooling implementation and provided you with an example of loading external database provider. This knowledge should help you in setting up your web-applications along with Helicon Ape in a very
efficient way.

Yours sincerely,
Helicon Tech team.