Re: How to update multiple rows atomically

From: paul c <>
Date: Sun, 30 Jul 2006 03:54:28 GMT
Message-ID: <U3Wyg.272462$iF6.46412_at_pd7tw2no>

Bob Badour wrote:
> Marshall wrote:

>> ...
>> Paul,
>> I'm also unsatisfied.
>> I have done a fair bit of concurrent programming. I've become
>> reasonably facile with locks and so forth, and can write complex
>> multithreaded Java programs without deadlock or race conditions.
>> (Mostly.) But I'm not happy with it. Even if *I* can do it, it is
>> often the case that other people on my team can't. I think even
>> the built-in support  for concurrency in Java is too low-level.
>> As has been said before numerous times, shared state concurrency
>> is the wrong default.
>> ...

> The only really interesting thing I have read regarding concurrency and
> databases was in Dennis Shasha's performance tuning book. What was it
> again, though? One of these days I really do have to unpack. It's been a
> year and a day since the purchase of this house closed, and I still have
> not unpacked.
> One of these days I have to get over this procrastination thing.

Heh heh, Edward de Bono gave this advice about how a neophyte should approach trying to master a field - buy all the books you can afford but don't read them, just keep them for reference!

When it comes to concurrency, I've pretty much blown my load once I say that a dbms needs to offer nothing more than a way to serialize a group of statements. Maybe this is the equivalent of the TTM comma operator.

But I'll ramble on anyway. Personally, I've found that users are fine with apps that very occasionally time out because of races or simple contention. They don't find this unreasonable as long as invoking a retry isn't onerous, which the app designers can cater for and as long as they don't have to undo partial work, which the dbms should cater for.

Normalization sometimes goes a long way - I can remember two different systems that were replaced, one IMS and one ACP, both so-called OLTP systems with thousands of concurrent users who were accustomed to attempting certain back-office inventory functions on a scheduled basis, like only at lunchtime on the third Thursday of the month! These systems had massive logical records with sometimes hundreds of 'fields'.   Users were delighted with the replacement systems that let them do those functions more or less at will with only rare misfires. It was really only a matter of re-thinking the schemas for a few high-frequency 'tables' and using very selective locking for the high-frequency transactions that the back-office ones were competing with. I can recall adding sentinel logic to a few logical transactions but rarely for small systems that had only dozens of users and after all, RT allows multiple equivalent logical 'arrangements'. The sequence of user actions is often pre-ordained, implying that certain locks make other locks redundant. Similarly for the mix of types of transactions at peak periods. Concurrency is as much part of an app's spec as anything else and it's not hard to predict it based on schemas and transaction volumes with nothing much besides Little's Law.

No experience with so-called concurrent languages nor massive internet systems but I imagine the basic techniques are similar, eg., think of an app that has both high-use and intensive functions as two apps, imagine separate schemas and then make a combination that marries them. If things still look tough, go back to the requirements. In a big system (which is where the big contention problems happen), there are always frivolous requirements that the big boss is willing to trash once their performance implication is explained.

Sometimes I think it is just undisciplined ego, "because it's there", that drives people to make a problem that needs to be solved out of every phenomenon whereas I think some problems are meant to be avoided, not solved, like certain back alleys late at night. There's lots that RT is silent about and that's okay by me - it's about a model for handling data, not a prescription for a modelling language. After all, RT is silent about disk head seek times too.

p Received on Sun Jul 30 2006 - 05:54:28 CEST

Original text of this message