Scott Mattocks has posted the next "letter" in his LUCID development series (more here) - the I is for Isolation:

Applications are a collection of individual components; they pull together the contributions of individuals to create something which is greater than the sum of its parts. If one piece breaks down, and the system is not prepared to put it in quarantine, the entire application can come crashing down. [...] The best way to stave off this infection is to prevent it at the source. Keep the application happy by making it more resistant to implosion.

He talks about the "code jerks" of your application that hog resources or functionality and cause general problems for the application as a whole. He notes that sometimes it's the result of a third party, but it can also be internal (and more difficult to find). He gives a more specific example of a database wrapper class and some suggestions of things to do as failover (ex. used cached data or read from a secondary).

Following up on his previous post about transaction-level isolation with the SQL Server driver, Brian Swan has this new look at an additional option - snapshot isolation.

I'll cover the snapshot isolation level in this post, and (as in my earlier post) I'll look at what happens at the database level when using a particular isolation level (rather than concentrating on PHP data access code).

He introduces snapshots for those not familiar with them - the idea of making a set of data available to other users without having to lock the database in a certain state (also called row versioning). He shows how to turn on the isolation functionality and set it to work with a transaction. With the snapshot created, he shows the SQL needed to fetch the snapshot of data and, of course, how to read it in PHP with the help of the SQL Server driver.

On his blog today Brian Swan has posted the results of some of his research on transaction isolation levels in SQL Server PHP applications.

Last week I had the good fortune of presenting at the the Seattle PHP Meet Up on a topic I knew only a little about: transaction isolation levels. It was fun doing the homework to learn more and I'll share what I learned in this post. This post is only somewhat PHP-specific. I'll focus largely on the concepts behind database transactions and isolation levels. Most of the concepts I'll look at are database agnostic (although I will use SQL Server as the vehicle for explaining the concepts) and are supported by most relational database management systems out there (e.g. SQL Server, MySQL, Oracle, DB2, etc.).

He introduces database transactions for those not familiar (a key to understanding the rest of the post) and some PHP code that connects to a SQL Server and begins a transaction to update some banking information. He uses this example to show how to set up isolation levels like "READ UNCOMMITTED", "READ COMMITTED" and "SERIALIZABLE".

Jens Schauder has an interesting suggestion about the development environment for your projects - one database per developer.

How many databases run in your teams development environment? One for the complete team? I have seen many places like that, but please tell me: Why? You aren't working on a shared files system aren't you? How is a developer supposed to change the structure of that database without interrupting the work of the other developers? And just in case you haven't noticed: Pretty much every RDBMS vendor offers free versions of their database which can run on a developer machine.

He suggests that every developer needs their own isolated database instance where they can run rampant through the data and only cause any real issues (or correct major ones) without having to worry about the impact on others. Keeping them in sync is a whole different story, but can be helped with something like fixture data.

Matthew Turland has a new post today about isolating tests in PHPUnit testing to try to avoid overlap in the resources each needs.

One requirement of the test suite was that some test methods had to be run in a separate process since class declarations reside in the global scope and persist until the process terminates. So, I slapped a @runInSeparateProcess annotation in the docblock of a test method with that requirement, ran the test suite'¦ and watched that test method fail because the class was still being declared.

After come close examination of his code and the PHPUnit source, he found the issue - a misunderstanding of how the preserveGlobalState property should be set. For it to work as he wanted, it needed to be set before the run() method was called for test execution. To correct the issue in his code, he overrides the run() method to set the value and call the parent.

Adding on a bit more to a previous post of his look at test isolation (ex. global variables from one test do not effect any others') with an update he's made to the PHPUnit code concerning the isolation.

Since the previous posting, I have added a backup/restore mechanism for static attributes of classes to PHPUnit. This is yet another feature of PHPUnit that makes the testing of code that uses global state (which includes, but is not limited to, global and superglobal variables as well as static attributes of classes) easier.

Two graphs illustrate the difference - one showing a normal run and another with this new feature in use and showing off the performance increase it can give.

Sebastian Bergmann as a new post talking about a few of the features of the PHPUnit unit testing framework, especially test isolation.

Some of PHPUnit features come with the cost of a performance penality. This posting explores the effect of the --no-syntax-check, $backupGlobals = FALSE;, and --coverage-html options.

He compares benchmarks for a test with few different settings - $GLOBALS, syntax check and code coverage (including graphical output of the execution times on the various parts of the tests).

On the PHP in Action blog today, there's a quick new post that talks about not only using the Smarty templating system but also a method for testing it to check for any kind of possible failure.

As I mentioned in my blog post on Paparrazzi testing, Uncle Bob (Robert C. Martin) has discussed how to test web templates or server pages. Since I'm currently working with Smarty templates, I wanted a simple way to run tests on them without needing to deal with a web server and the page navigation in a full web application.

Thankfully, he's found a nice, simple method for running tests against the Smarty engine (and includes that in the post - an interface to Smarty and the example test case to run against it).