L-P Huberdeau

The end of a PHP Quebec conference has two primary consequences: I can finally rest, and I need to catch up on work. Unlike the previous years, I was attending as a speaker and not an organizer, so I could actually enjoy the conference. My session was the very first on Thursday morning and it went pretty good, except that I had no projector for the first 10 minutes and had to improvise a little to compensate. It completely messed up my prepared flow and I ended up forgetting a lot of elements. On the other hand, the session was very interactive and I had tons of questions. I was not expecting so many people to attend to the session. The room was filled and organizers told me they actually added some chairs, but I didn’t notice that part.

After my duty was over, I could enjoy the conference. I attended to a few sessions and skipped some to talk with other people hanging around, mostly sponsors and speakers as regular visitors don’t skip sessions too often. Since the wireless access was unreliable, less people were answering their emails than usual. According to everything I heard, the wireless access was the only downside of the hotel.

The very first session I attended was Andrei’s talk on PHP 6 and unicode support. The possibilities made available with the built-in unicode support is simply amazing. Of course, it is even more when you actually need to work with non-latin characters, but it can still do quite a few nice things for us french speaking people and will probably solve all those endless encoding problems, at least on the server side.

After Andrei’s presentation, I took a break from sessions and realized at around 3 PM that I was missing Rob Richards session on SOA. I entered the room as quietly as I could and sat in the back. Of course, I missed a little bit of context, but Rob did a great job of exposing concerns of small companies when it comes to SOA. The only pieces of code appeared in the last few minutes of the presentation, a strong demonstration that technology is not the problem in this situation.

That was it for the first day. On Friday, I did not even try to wake up in time for the first session. I took the decision of sleeping in my bed instead of on a chair disturbing the speaker. I woke up in time for the second one, but when I made an attempt to join Laura Thomson’s session, the room was packed. At that time, I asked myself if staying in bed would have been a better decision.

Afterwards, I attended Kitman Cheung’s session on native XML support in DB2. Of course, it was some sort of sales speech and not so many people attended. It was a decent presentation. For those interested in storing XML in their database, it provided the desired information. I personally spent half the session trying to get DB2 running on my laptop. It really is not as easy as MySQL to install. After the session, Kitman gave me a hand to get it to run and all went fine. I still need to find some time to make serious tests with it, but that will have to wait after I catch up on all those things I was supposed to do on the 2 conference days.

Afterwards, I headed for John’s top PECL picks. I love PECL. The session covered phar, xdiff, zip, fileinfo, ssh2 and APC (but only after questions from the audience). I think the possibilities made available with xdiff were quite impressive, but more examples would have been good. The topic of the session was good, but generally, more concrete examples would have been nice to see.

Next, I attended to Graham Charters’ session on SCA. Last year, his session on SDO did not attract many people. I was in the room, but I was so tired, I didn’t understand anything. This time, the session attracted a lot more visitors, probably caused by Rob Richards pitch. SCA is the next step on SDO. It uses SDO to serialize data in order to distribute it across different services. If you want to expose SOAP services, SCA is definitely the easiest option around, and it will even expose JSON and XML-RPC services on the way if you ask for it. Although the extension is still in development and is not quite mature in this time, it’s one of those extensions you should keep an eye on.

The conference was over, but for those staying in Montreal a little more, there were more parties and the traditional visit to the sugar shack, which ended in a snowball fight.

This is something I always found annoying. When dividing your application in a proper object model, or even a procedural model for that matter, you end up with situations where functions and methods perform multiple queries on the database, or make other calls that modify the data. Transactions exists to make sure all those modifications are cancelled if one query happen to fail. There are two ways to deal with transactions: rely on the parent call to handle the transaction or handle it yourself. The first case breaks one of the basic purposes of design my asking the parent to understand the details of the operation and the second one will break as soon as the function is called from a context where a transaction is already active.

My solution to this is to get each function to believe they are in control of the transaction, which may or may not be true. The solution is very simple: let each call begin the transaction, but only the first one to call it in a tree really begins the transaction. The following class does exactly this. Each scope willing to isolate a transaction instanciates a Transaction object. If the function terminates in an expected way, a call to commit must be made. Otherwise, failure is assumed and the transaction will roll back, but only if the scope actually owns the transaction. Even commit is a nil operation if the scope does not own the transaction. Some of you might have noticed, this is strongly inspired by C++ auto_ptr.

class Transaction
{
	private static $transactionActive;
	private $transactionOwner;

	function __construct()
	{
		if( !self::$transactionActive )
		{
			self::$transactionActive = true;
			$this->transactionOwner = true;
			get_db()->beginTransaction();
		}
	}

	function __destruct()
	{
		if( self::$transactionActive && $this->transactionOwner )
		{
			self::$transactionActive = false;
			get_db()->rollBack();
		}
	}

	function commit()
	{
		if( self::$transactionActive && $this->transactionOwner )
		{
			self::$transactionActive = false;
			get_db()->commit();
		}
	}
}

The get_db() function is a simple function to return the PDO object and lazy-load it as required.

I use this technique by throwing an exception whenever an error occurs. The controller-level is responsible for catching all exceptions and log or report them as required. Of course, some higher levels also catch exceptions and handle them or re-throw them with a more specific type and message (such as converting PDO duplicate entries to a readable message).

With this simple class, the entire system can ensure transaction isolation without having to worry about the context. I find it very helpful.

Of course, it only works in PHP 5 as destructors are required.