Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <468FE946.9070300@amberpoint.com>
Date: Sat, 07 Jul 2007 12:28:06 -0700
From: Bryan Pendleton <bpendleton@amberpoint.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: any plans for mvcc?
References: <9260c1550707060234u3ab12c3es99ec55e6c82fce30@mail.gmail.com>
In-Reply-To: <9260c1550707060234u3ab12c3es99ec55e6c82fce30@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> Is there currently any plans for multi-version concurrency control for
> a future release of Derby? If so what is the rough timeframe?

I haven't heard of anyone working on such a feature, but we're always
interested in getting more people to join the community and participate
in adding more features to Derby! http://db.apache.org/derby/derby_comm.html

> The pessimistic locking mechanism currently employed by Derby makes it
> harder to scale application built on Derby and can easily cause
> deadlocks. It's hard to support multiple users for Derby with this
> concurrency control.

Many very sophisticated large-scale applications have been built over
the last 40 years using this model, and Derby contains a rich set of
the basic features necessary to build such applications:
  - multiple isolation levels
  - update-mode locks
  - row-level and table-level locking
  - LOCK table statement
etc. See this page for more information:
http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts30291.html

It is true that you have to take these issues into account during
application design and implementation, but I believe you can successfully
build highly scalable applications which support multiple users with
a high degree of concurrency using the current Derby feature set.

thanks,

bryan