any plans for mvcc?

[Jon Tirsen <jo...@tirsen.com>]

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

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.

Cheers,
Jon

Re: any plans for mvcc?

[Bryan Pendleton <bp...@amberpoint.com>]

> 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

Re: any plans for mvcc?

[Stanley Bradbury <St...@gmail.com>]

Jon Tirsen wrote:
> Is there currently any plans for multi-version concurrency control for
> a future release of Derby? If so what is the rough timeframe?
>
> 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.
>
> Cheers,
> Jon
>
Hi Jon -
I think you need to raise this question to the derby-dev list as it 
appears to involve changes to the Derby engine code rather than 
application development using Derby.  Is this an effort you might be 
willing to contribute to?