In a new post to his site Stefan Koopmanschap covers the creation of idempotent commands, that is, commands that can only run one at a time without having to worry about possible overlap.

One of the things you may run into these days (and that I had to solve this week) is that these days we provision all servers similarly (or according to their role). This may also mean that you provision several of your servers to run the same cronjobs at the same time. However, some tasks may not be run multiple times, and especially not at the same time. In a symfony project I'm working on, I was tasked with making sure some of the cronjobs would only be run once, even if started on several servers at the same time.

He then goes through the process he followed for adding in the locking making use of the console.command and console.terminate hooks in the Symfony Command component. He then made use of the arvenil/ninja-mutex package to do the actual locking. He works through his decision process on when to lock and how to detect which commands needed to be locked. He ends the post with the code for the listener to create and release the lock automagically when the command has finished.

The Exakat.io blog has a post with an interesting method for preventing the execution of multiple instances of a script at once - locking execution with an external indicator (like files, semaphores and streams/sockets).

Like everything, it all started from a simple problem : how to prevent multiple PHP scripts at the same time. And turned into an odyssey of learning, full of evil traps and inglorious victories. In the end, it works, that’s the most satisfying and it possibly matters to no one except me. But "the way is the goal", as said Confucius, so, I decided to share the various findings.

Exakat runs in command line, and it uses a graph database. The database is central to the processing, and it is crucial to avoid running several scripts at the same time : they will write over each other. So, the problem is simple : preventing several instances to run at the same time, on the database. In commandline, there is no web server that may serve as common place between scripts, sharing some memory and implementing a locking system. It requires to use another common ground : the system.

He shares some of the methods he tried to help prevent the simultaneous execution of the Exakat process including:

• file locking using flock
• creating a "lock" file
• making it "crash proof"
• using semaphores
• using a socket for the lock

He describes some of the issues he found when running the tool using locking inside of a Docker container and, finally, the use of sockets and streams to place a "hold" until the script closes (also preventing issues on a crash). He ends the post talking about the "final boss" in his battle for locking support - the handing off of the socket connection to another process between parent and child. The final list in the post is a list of each method he tried, their benefits and downsides (but only in certain situations).

In a new post Tobias Schlitt looks at a part of the recently released eZ Components version 2008.2 that includes, among other things, Webdav support.

My tasks for 2008.2 were dedicated to the Webdav component. This package allows you to easily integrate WebDAV access features into your applications. With the earlier 2007.2 release, this component was born. By then, it supported just rudimentary WebDAV features (compliance class 1) and we focused on its architecture to make it as flexible as possible.

He explains how a commonly requested feature - locking - was implemented in the component. You can find out more about the feature/component in this article from Tobias on the eZ Components website.

IBM developerWorks has another new tutorial today with a look at locking down your PHP applications - "four security rules you can't violate".

In this tutorial, you'll learn how to add security to your PHP Web applications. It is assumed that you've been coding PHP Web applications for at least a year, so it won't cover the basics of the language (either conventions or syntax). The goal is to make you more aware of what you should be doing to secure the Web applications you're building.

This tutorial teaches you how to guard against the most common security threats: SQL injections, the manipulation of the GET and POST variables, buffer overflow attacks, cross-site scripting attacks, data manipulation inside the browser, and remote form posting.

You'll need a system already running PHP (at least version 4.x) and MySQL on a web server (Apache or otherwise). They look briefly at some of the common security issues plaguing web applications these days before moving on to the four rules:

• Never trust outside data or input
• Disable PHP settings that make security difficult to enforce
• You can't secure it if you can't understand it
• "Defense in depth" is your new mantra

They take a look at each of these and use the rest of the article (8 more pages) showing you how to keep yourself safe from these issues.

IBM developerWorks has another new tutorial today with a look at locking down your PHP applications - "four security rules you can't violate".

In this tutorial, you'll learn how to add security to your PHP Web applications. It is assumed that you've been coding PHP Web applications for at least a year, so it won't cover the basics of the language (either conventions or syntax). The goal is to make you more aware of what you should be doing to secure the Web applications you're building.

This tutorial teaches you how to guard against the most common security threats: SQL injections, the manipulation of the GET and POST variables, buffer overflow attacks, cross-site scripting attacks, data manipulation inside the browser, and remote form posting.

You'll need a system already running PHP (at least version 4.x) and MySQL on a web server (Apache or otherwise). They look briefly at some of the common security issues plaguing web applications these days before moving on to the four rules:

• Never trust outside data or input
• Disable PHP settings that make security difficult to enforce
• You can't secure it if you can't understand it
• "Defense in depth" is your new mantra

They take a look at each of these and use the rest of the article (8 more pages) showing you how to keep yourself safe from these issues.