Re: Concurrency in an RDB

Bob Badour wrote:
> Michael Ortega-Binderberger wrote:
>
> >
> > Hi, Sorry, but found this thread rather amusing, adding some comments in
> > between below.
> >
> > On Fri, 8 Dec 2006, Bob Badour wrote:
> >
> >> David wrote:
> >>
> >>> Bob Badour wrote:

[snip]

> >> Why should we restrict ourselves to a tiny special class of applications?
> >
> > Deos not matter, whatever the application writer wants to do. If long
> > write-transactions are called for, thats ok. No need to restrict ourselves.
>
> Just to make sure everyon is on the same page, we were not discussing
> application writers but dbms implementers. Designing a 'dbms' that
> strictly serializes all update transactions restricts all users of the
> dbms for all time.

Yes. The question I want answered is whether that restriction is reasonable, in practise at the application level. Can updates be decoupled from CPU intensive tasks?

[snip]

> > I comlpetely agree, the notion that one mutex RDB wide is good is
> > simply, well, too simplistic. I agree that this approach has been
> > rejected long ago.
> > Concurrency is needed at the IO level, but also at the overall logical
> > schema level. In your proposal, you lock the whole db exclusively for a
> > write (which you assume incorrectly costs very little, writes cost-a
> > lot). Say why is this needed? Why not better exclusively lock only the
> > taxle which you will modify? ie have a mutex per table. Surely this
> > increases concurrency even more per your definition. Now writers can
> > proceed concurrently as long as they write to different tables. This is
> > clearly superior to your original proposal per your measure of concurrency.
> > It is also completely unworkable. It will easily lead to
> > inconsistencies in the database. So lets come up with another approach,
> > one mutex like before for every table and one "super mutex" for the
> > whole RDB (using here mutex in a misleading way, systems programers tend
> > not to understand differences between locks and latches).
> > So lets suppose I lock the table in exclusive mode when I want to change
> > it, but hot to keep things ok? lock the new "super mutex" in a new mode:
> > I'm planning to change an underlying table. So you start to have more
> > lock modes, and more concurrency.
> > I won't spend the time here explaining the details how all this works.
> > Just think about it a bit and see how this can improve concurrency and
> > still keep things ok. Once you have thought about it, you will see its
> > far more complicated than your original proposal, but also has more
> > concurrency.
> > Welcome to multigranularity locking. As another poster said, go read
> > the literature before posting already rejected ideas.
>
> I think the original poster may have also confused locks with
> transactions, but even trying to substitute one for the other to make
> the most possible sense doesn't make his position entirely sensible.

What's hard to understand? I propose there is a single mutex on the whole DB. A mutative transaction has to get an exclusive write lock on the mutex. A read-only "transaction" has to get a shared-read lock on the mutex.

> Transactions may acquire and release many locks over the duration of the
> transaction which may be orders of magnitude longer than the duration of
> any lock.

Yes, in the conventional, fine grained locking strict 2PL approach.

[snip]

Cheers,
David Received on Sat Dec 09 2006 - 04:57:07 CET