Re: [Exist-development] [Exist-open] Performance of concurrent read queries.

[James F. <jam...@ex...>]

On 30 August 2010 18:19, Jason Smith <js...@in...> wrote:
> I understand.  The solution we have in place right now is similar to the solution you mentioned, but we put it in place a while ago.  Augmenting the locking with a singleton lock does, indeed, work.
>
> That was my first replacement of the locking mechanism.
>
> The second replacement I've come up with allows two read queries to run simultaneously, even when they target the same collection, and when multiple collections are used simultaneously.  And it enforces atomic read and write operations, something the current locking does not appear to do as well (I am still researching this one).
>
> It isn't as concurrent as I would like (due to dom.dbx locking), and we still need to put it through its paces to test for stability.

Guys,

I have followed the thread and (as u would expect) agree mostly with
Wolfgangs thoughts and defo welcome any and all contributions but we
have to be careful to revisit all original assumptions. I am not
saying its a bad goal to try and make non index-assisted,
non-optimized access to the DOM more performant, but in a database
indexes are so important I think we sometimes ignore corner cases,
though I would be interested to see what knock on impact to general
performance with this modification we have to be careful with respect
to stability of the codebase.

Can I suggest a irc chat or skype call ... email sucks for resolving
deeper levels of tech detail.

James Fuller