Monday, November 26, 2007

Time for a 2nd opinion

One of my passions and something I claim to know more than a little about is the Oracle database. I'm still learning and hopefully always will be.

It probably comes as no surprise that one of the sources from which I've learned a tremendous amount of information is Tom Kyte of Oracle (http://asktom.oracle.com). Now, Tom spends a large amount of time answering questions from us mere mortals on all topics Oracle.

The other day I was browsing the site and saw that the 'Ask a question' button was available. For those of you that read asktom regularly you'll know this is a fairly rare occurrance, as there's always a large number of questions awaiting Tom's attention.

So, I thought I'd ask a question regarding a semi-hypothetical situation that had cropped up with a legacy application. I'd been trying to figure out a way of reducing the serialisation time when trying to process records in a table (not a batch process - an online process where we need to process one at a time). I did my research and came across a few things I didn't know previously - including the undocumented SKIP LOCKED clause on SELECT FOR UPDATE and some alternative procedural approaches. So, I posed the question to Tom, was this a valid approach?

To answer, Tom pointed me in the direction of something I hadn't even considered but which was built right for the purpose, Oracle AQ. Fitted the problem domain exactly without requiring any of the workarounds I had thought of to cope with limitations of procedural approaches (all the what ifs...). Now with the original idea for the question being a legacy app, there'd need to be some adjustment to get AQ in there but a whole lot less work than trying to cope with the error scenarios and making sure we catch them all.

Moral of the story - It's reminded me it's always wise to get a second opinion on any design/idea you come up with for a particular situation. We techies sometimes have a tendency to overlook the obvious and reinvent the wheel when the answer is often right under our noses...

Thanks Tom!

No comments: