Dave Short

So, for my final project in CS 365 (Databases), I’m designing a Wikipedia-style encyclopedia. Not very original, but it gets the job done. And it’s kind of fun to code.

Until today, however. Since this is finals week, I’ve been concentrating on other things until today. The project is due tomorrow. I already had a lot of it done (strange for me, I know, but I’m trying to get out of here), and had seen a lot of e-mails over the weekend about how the DB server we were using was going down and back up as it was fixed. I didn’t worry too much, because as of last night it was supposed to be up and strong.

Imagine my horror, then, as I logged on to the site to see what needed to be done, and got all sorts of errors, most of them involving the MySQL server’s refusal to connect. Some pages, mostly display pages, were still working. So I could browse to articles, list them, and so on, but I couldn’t create or edit them. I was understandably upset, because I also couldn’t implement the access controls or categorization features that my proposal said I would.

After some investigation, I determined that the problem arose when I requested more than one SQL connection at a time. In theory, I only needed one at a time, but my architecture was designed around a Database class, which you could have more than one of. One class for one connection. I also had some static classes for doing things like manipulating articles, categorizing them, linkifying them, and so on. All the edit pages would usually verify that the article in question exists, then call these static classes to do what they needed to do. So the calling page was creating a DB connection, then the static classes would, in order to do what they had to.

My options were looking pretty grim. Do I switch DB servers, and troubleshoot that nightmare? Do I change my whole engineering scheme with T-minus 20 hours and counting?

After some general freaking out, I realized that my pages revolved around a static call in the Database class called getConnection(), which returns a connection to the default database. The wheels in my head started turning, and I realized that since every one of my requests for a database connection go through this method, I could somehow use it to save the day.

The trick was to create a static class member called $working, which held the connection to one, and only one, database. So I changed my code. From this:

public static function getConnection ()  
{
   return new Database();  
}

To this:

public static function getConnection ()  
{
   if (self::$working == NULL)
    self::$working = new Database();
   return self::$working;  
}

Since I essentially had a factory method to get the database connections to begin with, I merely needed to change this method so that it created the first connection, but didn’t do so on subsequent connection requests. Instead, it returns the already-existing connection. Since all my pages use this method, it means that they all use one and only one server connection. I changed the code, uploaded, and… voila! It worked perfectly.

Imagine the trouble I’d be in if I hadn’t done this to begin with. This is why I love OO programming. Because if you start with well-engineered code, then a major change like this can fix everything, and break nothing. Long live Object-Oriented Programming!

Update:I would be remiss not to mention that this is the Singleton design pattern, which my buddy and classmate Dylan pointed out I had omitted from the original post.