That blue thing that I am running PowerPoint on during my talks is an Alienware Area51-m laptop. Heavy like a block of lead, battery life of about 2 hrs (which makes me carry two), but very fast and "feel good". Except for some minor annoyances, I am happy with it for about a year now. And I don't think I have every had a machine that was still faster than most of the other machines out there 12 months...
Wow. It's been a long time. 2 years again, already? Mr. Forte lets me stay at his house and invited me to his Christmas party in New York and since I am not going to Denver for the rest of the year as I was planning and I still need a few miles to retain my current status tier with Lufthansa for '05/'06, there wasn't much to think about. I am thrilled to go back. In the two years I...
Now that we have a way to detect deadlocks and similar error conditions we might encounter during a transaction, we need to find a mechanism that will allow us to back out of the doomed transaction and retry the failed operation. The good thing about transaction failures of that sort is that you can essentially retry as often as...
Before we can do anything about deadlocks or deal with similar troubles, we first need to be able to tell that we indeed have a deadlock situation. Finding this out is a matter of knowing the respective error codes that your database gives you and a mechanism to bubble that information up to some code that will handle the...
Deadlocks and other locking conflicts that cause transactional database operations to fail are things that puzzle many application developers. Sure, proper database design and careful implementation of database access (and appropriate support by the database engine) should take care of that problem, but it cannot do so in all cases. Sometimes, especially under stress and other situations with high lock contention, a database just has not much of...