Re: Concurrency in an RDB

David wrote:

> I have some thoughts on how best to achieve concurrency in an RDB. You
> may want to keep in mind that I am a "systems programmer" with
> little experience in using an RDB. I'm posting to this newsgroup to
> see whether my ideas have a reasonable basis.
>
> Consider that a single mutex is used to protect an entire RDB. This
> mutex offers shared read / exclusive write access modes. It avoids
> writer starvation by blocking further readers once one or more writer
> threads are waiting on the mutex.

Some write transactions take a long time to complete and will thus lock everyone else out of the database.

[snip]

> Exclusive write access to the entire RDB means there can never be
> dead-lock. This eliminates a lot of complexity and overhead.

It also eliminates almost all useful concurrency.

> In some database applications repeated dead-lock scenarios occur, and
> the database can become very inefficient because transactions are
> continually aborted and rolled back.

Which applications are those? And why are dead-locks necessarily a problem for those applications?

[snip]

> In a shared read mode we get the ultimate in concurrency.

Shared read/shared write is the ultimate in security. The use of the log to provide multiple concurrent views of uncommitted data gets that job done.

[snip]

> Subject to integrity constraints, mutative work can be fine grained.
> For example, it is not necessary to add a whole family at once to a DB;
> it is possible to add one person at a time.

One of the great things about the relational model is set-level operation. It is not necessary to add one person at a time when one can add a whole family.

[snip]

I suggest if you look at any text on concurrency and transactions in dbmses, you will find your proposal has been well-considered and long-ago rejected. Received on Fri Dec 08 2006 - 04:37:07 CET