Ian is right. The U-lock will be promoted to X lock only after all the other
S locks are released. But I thought the U-lock will wait forever until it
can be promoted to X lock, no matter what LOCKTIMEOUT db parameter you
setup. (Maybe I got wrong, I am not totally sure about this. You can do a
test).
There is always some comprise between high concurrency and data integrity.
This is an very old concurrency control policy, it is used during the time
when the dbms are used by highly intensive data update OLTP applications.
Most systems are client/server two tier architecture or earlier like
Mainframe. Since web/internet applications are accepted by more and more
systems. All the dbms producer become to adjust their concurrency control
policy in order to handle the demands of a growing number of concurrent
application requests. IBM has been doing a lot of improvement on this issue.
But it looks like the documentation didn't cover those new parts.
"Ian" <ia*****@mobileaudio.com> wrote in message
news:41**********@corp.newsgroups.com...
Christoph Zeltner wrote: Thank you for your answer. If a transaction has an U-lock and another
transaction has a S-lock on the same resource, what happens, if the
U-lock wants to promot to a X-lock ? Does it have to wait for the S-lock (i
think so) ? So can a promotion starve ? Very low down in the internals, i
know, but maybe you know that.
Yes, the change from a U-lock to an X-lock will wait for the S-lock to
be released. DB2 has a configuration parameter that controls how long
an application will wait for a lock before timing out.
You can read more about this in the DB2 UDB documentation. See:
http://tinyurl.com/46myf
For more information about locks (and links to other pieces of doc
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----