Simple Synchronization

Today I felt sick, but I worked anyway. Made sense especially considering the weather was all rain and wind, over 70mm locally in a 24-hour period.

I made some good progress on a couple of tasks, including process synchronization and user interface optimization, so that made me feel a bit better.

One project of mine uses an ASP.NET web services back end data access layer for a WinForms rich client app that’s distributed from a web server (sort of a .NET 1.1 precursor to ClickOnce), and one aspect of this is generating a monotonically increasing identifier which is reset each year, making it unsuitable for an Oracle sequence (without resorting to DDL manipulation) or even as a primary key. In any case, I originally wrote this app six years ago, and was a little lax in the processing to calculate the next available number. It does a simple “max” aggregation on the field and adds one to it, or returns 1 if it’s the first one in a year, this as opposed to explicitly locking the table or somesuch. And for six years, it worked fine, until this week when a user asked how we could get duplicate identifiers.

Rather than fiddle with locking tables in Oracle, because I wasn’t necessarily in the frame of mind to tackle something like that while a tad under the weather (pardon the pun) I decided to simply serialize the web server DAL method which assigns the identifier. The way the DAL is abstracted, there are a mere five statements in this method, the last of which is the call to execute the stored procedure. Since the first four methods are very inexpensive (setting up the command and parameters) I serialized the entire method using the following method attribute:

<MethodImpl(MethodImplOptions.Synchronized)>

This ensures that at monst one thread can enter this method at a time. These declarations exists in the System.Runtime.CompilerServices namespace.