hi,

i am writing a thesis on the concurrency control in db2 udb and oracle. I
found in the documentary of db2, that
a resource holding a (U)pdate-Lock can still be requested by a read-lock
(e.g. S). If the U-Lock wants to convert to a write-lock, does the
transaction have to wait for the transaction with the S-lock to finish ? Can
it starve ? Is this the symmetric RUX-Protocoll ? Questions, so many
questions ...

Thx.

Christoph Zeltner

Yes, U lock is compatible with S lock. Because U lock will be promoted to X
lock, instead of asking for S and X lock separately to search and update the
target object, this can avoid deadlock in some cases.

"Christoph Zeltner" <christoph.zeltner@web.de> wrote in message
news:cdp2vn$vkn$01$1@news.t-online.com...[color=blue]
> hi,
>
> i am writing a thesis on the concurrency control in db2 udb and oracle. I
> found in the documentary of db2, that
> a resource holding a (U)pdate-Lock can still be requested by a read-lock
> (e.g. S). If the U-Lock wants to convert to a write-lock, does the
> transaction have to wait for the transaction with the S-lock to finish ?[/color]
Can[color=blue]
> it starve ? Is this the symmetric RUX-Protocoll ? Questions, so many
> questions ...
>
> Thx.
>
> Christoph Zeltner
>
>[/color]

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.

Thx
Christoph
"Fan Ruo Xin" <fanruox@sbcglobal.net> schrieb im Newsbeitrag
news:JQ%Lc.2702$wg2.2672@newssvr15.news.prodigy.co m...[color=blue]
> Yes, U lock is compatible with S lock. Because U lock will be promoted to[/color]
X[color=blue]
> lock, instead of asking for S and X lock separately to search and update[/color]
the[color=blue]
> target object, this can avoid deadlock in some cases.
>
> "Christoph Zeltner" <christoph.zeltner@web.de> wrote in message
> news:cdp2vn$vkn$01$1@news.t-online.com...[color=green]
> > hi,
> >
> > i am writing a thesis on the concurrency control in db2 udb and oracle.[/color][/color]
I[color=blue][color=green]
> > found in the documentary of db2, that
> > a resource holding a (U)pdate-Lock can still be requested by a[/color][/color]
read-lock[color=blue][color=green]
> > (e.g. S). If the U-Lock wants to convert to a write-lock, does the
> > transaction have to wait for the transaction with the S-lock to finish ?[/color]
> Can[color=green]
> > it starve ? Is this the symmetric RUX-Protocoll ? Questions, so many
> > questions ...
> >
> > Thx.
> >
> > Christoph Zeltner
> >
> >[/color]
>
>[/color]

Christoph Zeltner wrote:[color=blue]
> 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.[/color]

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! =-----

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" <ianbjor@mobileaudio.com> wrote in message
news:41023a37$1_1@corp.newsgroups.com...[color=blue]
> Christoph Zeltner wrote:[color=green]
> > 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[/color][/color]
U-lock[color=blue][color=green]
> > wants to promot to a X-lock ? Does it have to wait for the S-lock (i[/color][/color]
think[color=blue][color=green]
> > so) ? So can a promotion starve ? Very low down in the internals, i[/color][/color]
know,[color=blue][color=green]
> > but maybe you know that.[/color]
>
> 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! =-----[/color]