Re: Concurrency in an RDB

David wrote:
>
> Bob goes on about prior work like a broken record. His comments
> indicate good understanding of how conventional databases work - ie
> using pessimistic and fine-grained locking. However he betrays his
> arrogance. Although clearly very intelligent and knowledgeable he
> doesn't take the effort to understand me.
>
> For anyone interested (other than Bob who has stuck his fingers in his
> ears)

It may not be arrogance; perhaps Bob is simply as pessimistic as his preferred concurrency model...

>From what you've stated, it appears that you're proposing a completely
different concurrency model than conventional RBDMS employ. We can only assume that your ideas of using OT actually work and scale well; though, as you've stated, this is an area of research, so I expect that you have no evidence yet... and if you do, you probably are not prepared to divulge too much...

This does, however, simplify the question originally posed as you are dealing only with an in-process DBMS. I would expect that it would be possible (given this scenario) to completely avoid deadlock as *any* multi-threaded application must prove that it's threads can not deadlock, and the only actors in this scenario are your application's threads. This could lead to a light weight and very fast DBMS implementation indeed.

I'm struggling to think of reasonable use cases for long-running CPU intensive mutative transations. So far all I have are maintenance/administrative tasks like schema changes, during which time you want no concurrent transactions and would take the database offline.

Cheers,
Dan Received on Wed Dec 13 2006 - 00:17:39 CET