With this level of locking, UPDATE queries that do not involve columns of the tuple key can perform concurrently.
The argument will be "but chaos will ensue!" I don't buy it. With conventional row level locking, my updates will get overwritten by your updates, just with lowered concurrency. And, by definition, non-key attributes are fully mutable and irrelevant to identity or process; that's why they're non-key. High normal form schemas fit right in with this locking regime: tables are narrower, with fewer non-key attributes per table. The flatfile folks oft times argue that same-named attributes have to have separate ranges, depending on table; foreign keys and normalization are evil. May they fry in hell.
No comments:
Post a Comment