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 java( http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentSkipListMap.html ) 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. regards, Selcuk On Thu, Nov 24, 2011 at 5:57 AM, Emmanuel Lecharny <[email protected]> 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 > www.iktek.com > >
