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

[Jason S. <js...@in...>]

If you are referring to org.exist.storage.lock.ReentrantReadWriteLock, which serves as both the collection locking mechanism and the one used by "dom.dbx", "collections.dbx", etc., the problem is that this lock is a mutex.  The name is Reentrant...  However, the implementation uses a mutex over reads and writes.

The ideal would be to allow multiple readers and a single writer to any resource at any time.  The standard locking mechanism, when used with "dom.dbx", allows only one reader or writer at any time.  For long, unoptimized read queries, this results in a choke point on dom.dbx that looks to me like it slows down even optimized queries.

I hope I answered the right question...  :-)

-----Original Message-----
From: Dmitriy Shabanov [mailto:sha...@gm...] 
Sent: Sunday, August 29, 2010 12:56 AM
To: Wolfgang Meier
Cc: Jason Smith; eXist development
Subject: Re: [Exist-development] [Exist-open] Performance of concurrent read queries.

On Sat, 2010-08-28 at 19:06 +0200, Wolfgang Meier wrote:
> > Instead, eXist has artificially limited access to dom.dbx to a single thread (at a time).
> 
> The assumption is that - during a query - dom.dbx is only read at
> serialization time and only to read out a sequence of pages to display
> the final query result to the user.
> 
> It's a complex interplay between cache manager, transaction log and
> other components. I agree there could be ways to allow concurrent read
> access to dom.dbx at the same time, but we would need to carefully
> discuss the implications.

Would 'normal' lock mechanism be suitable here? Or any restrictions that
do not allow to use it?

-- 
Cheers,

Dmitriy Shabanov