Holidays officially began yesterday with a round of golf at Grand Pines GC followed by a very nice barbecue at Steve’s and Laura’s cabin. Golf sucked (57+48=105) but I had flashes of my old self when I wasn’t losing one of my 15+ new balls in the impassable bush. Derek was impressive as usual with his ability to hit the long ball, while Steve matched him with an 89, the highlight of which was an eagle on the 9th made possible by a brilliant 235yd second shot to inside 10 feet which he calmly drained. He bought us lunch to celebrate (plus I had no cash on me!) The BBQ was great, but time flew by. I swam in the lake (the only adult who dared) and played football with the kids, and we celebrated Bryan’s belated birthday. I got home much later than I’d planned, around 11:30pm.
Barb’s family arrives tomorrow so it should be a fun-fulled week. Regardless of what others want to do, I will be spending most of my time at home by the pool. I only get a week off this summer and I need to relax, regardless of what everyone else wants to do.
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:
This ensures that at monst one thread can enter this method at a time. These declarations exists in the System.Runtime.CompilerServices namespace.