directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Handling consistency issues with HBASE partition (was Re: HBase partition integration in trunks ?)
Date Mon, 29 Aug 2011 14:52:45 GMT
Hi Stefan,
Working on JDBM, I was wondering what kind of cosistency gurantees
does HBASE partition implemenation expose? In particular, do put and
fetch operations on the underlying master table and indices have ACID
properties? How about cursors? Do cursors see future changes as they
move back and forth?


On Tue, Aug 16, 2011 at 4:49 PM, Kiran Ayyagari <> wrote:
> On Tue, Aug 16, 2011 at 7:06 PM, Emmanuel Lecharny <> wrote:
>> On 8/16/11 3:22 PM, Kiran Ayyagari wrote:
>>> On Tue, Aug 16, 2011 at 6:45 PM, Stefan Seelmann<>
>>>  wrote:
>>>> On Tue, Aug 16, 2011 at 2:22 PM, Kiran Ayyagari<>
>>>>  wrote:
>>>>>> One solution would be to store two more elements in the ParentIdAndRdn
>>>>>> data
>>>>>> structure : the number of children directly below the RDN, and the
>>>>>> number of
>>>>>> children and descendant. That would probably solve the issue I'm
>>>>>> mentioning.
>>>>>> Of course, that also means we wil have to update all the RDN hierarchy
>>>>>> from
>>>>>> top to bottom (but affecting only the RDN part of the entry DN) each
>>>>>> time we
>>>>>> add/move/delete an entry. Note that we already do that for the oneLevel
>>>>>> and
>>>>>> Sublevel index.
>>>>> Just to make a point:
>>>>> I think, in the case of achieving SubLevel index evaluation with RDN
>>>>> index it becomes a costly and complex operation
>>>>> (recursive scanning and updating) where as with the current sublevel
>>>>> index it takes O(1) to fetch all the sublevel children of
>>>>> an entry.
>>>> Hm, evalutation can easly be done by using the reverse RDN index table.
>>> for one level it is straight forward, but for sublevel we still need
>>> to use recursion, no?
>> No, if we update all the parents when we add/move/delete an entry. That
>> means we have to update more than one RdnAndparent element (in fact, as many
>> as we have RDns but the namingContext in the DN). Nothing more though that
>> what we already do in the sub-level context.
>> Then we have a O(1) operation to get the number of children in the case of a
>> SUB search.
> if we are only talking about 'number of children' then this holds
> good, but not when it comes to getting the
> sublevel child entry ids, in case of existing sublevel index we get
> *all* the child ids in one lookup
>> Now, Stefan is right, fetching entries means we use more than one cursor for
>> that.
> yeap, the above step is where this many cursors will be opened to
> collect the entry ids
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
> --
> Kiran Ayyagari

View raw message