Mladen Gogala wrote:
> On Sat, 17 Dec 2005 07:57:14 -0500, Serge Rielau wrote:
>
>
>>The risks everyone takes by not running serializable/RR are real because
>>most don't truly understand the implications of other isolation levels.
>>
>>Column level locking is safe, just too expensive.
>
>
> Serge, I beg to differ. Sometimes, columns are logically related. It's
> easy to think of the logical disconnect among the two updating processes
> that would result in totally senseless claims. The world's most frequent
> last name is Wong. The world's most frequent first name is Mohammed. The
> conclusion that the world is full of people with the name Mohammed Wong is
> incorrect. That type of paradox is easy to construct and can easily break
> the logical consistency of your database. One would need to move all of
> the database mechanisms (foreign keys. trigers, constraints) from the row
> level to the column level to make is safe. I also believe that such
> "columns based database" would be too much for any computer of today, even
> things like HP SuperDome or SUn E15000 as every process would have to pass
> through an order of magnitude larger myriad of triggers, constraints and
> stored procedures just to update a single row.
>
> PS:
> ---
> My apologies to any Mohammed Wong who reads this. It wasn't personal.
>
Well, we agree on the price tag at least.
Now I have no clue how statistical column correlation has anything to do
with locking granularity.
Maybe if you could flesh out the example a bit more....
If the values of two columns depend on another and transaction A refers
to C1, then any change in column C2 by transaction B would also change
C1 and thus the column locking would hold.
So if I'm looking for a all the Mohammeds and you are changing their
names from Wang to Smith I do not see how that affects my query.
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
DB2 UDB for Linux, Unix, Windows
IBM Toronto Lab
Received on Sat Dec 17 2005 - 17:20:59 CST
