directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: AVL cursor problem?
Date Fri, 25 Nov 2011 07:51:06 GMT
I looked at the code some more and think that using read-write locks
might not be a good idea. There are cases where a cursor is held for a
partition and the same partition is changed. This makes it hard.

My suggestion is to use a ConcurrentSkipListMap implementation of
) rather than our own implementation of avl as the backing sorted map
for our avl partition. We can build cursors over this map using the
iterator provided by this map ( I did something similar to provide a
cursor for the index changes of a txn). This iterator is weakly
consistent, that is, it might show future changes but will show a view
of the map at least as of the time of its creation. This works for us.
Even if cursor shows future changes, our txn layer above should  take
care of this and provide a transactionally consistent view.

The cost of the common operations would be amortized o(logn)  with
this map. So, this is similar to AVL tree cost. Note that, we would
need to use ConcurrentSkipListMaps to store dup values.

Let me know if you think this sounds OK with you.


On Thu, Nov 24, 2011 at 5:57 AM, Emmanuel Lecharny <> wrote:
> On 11/23/11 2:03 PM, Selcuk AYA wrote:
>> Hi,
>> it seems that AVL cursors are not protected against concurrent
>> updates. Is this true or am I missing something?
> Kiran ?
>> The issue seems to be similar to the JDBM synchronization issues and
>> is a blocker for the txn work. We either have to do something similar
>> to jdbm or use a read write lock to provide synchronization. Read lock
>> in this case would need to be held by a cursor as long as it is open.
> ATM, we could add a read/write lock. AVL partition is just used for the
> schema partition and the configuration, we don't modify those guys very
> frequently, and we don't really care if we have a bit of contention for it,
> as the config is mainly read at startup and is not dynamic, and the schema
> is loaded into the SchemaManager, unless we modify it.
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message