Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of ayaselcuk@gmail.com designates
 209.85.212.50 as permitted sender)
MIME-Version: 1.0
Date: Mon, 29 Aug 2011 17:52:45 +0300
Message-ID: 
 <CALhXAG2Qe_Et72c6fw8hDKbVHVEhLhEGwJYzV-msWwiTu_Ez=A@mail.gmail.com>
Subject: Handling consistency issues with HBASE partition (was Re: HBase
 partition integration in trunks ?)
From: Selcuk AYA <ayaselcuk@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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?

regards,
Selcuk

On Tue, Aug 16, 2011 at 4:49 PM, Kiran Ayyagari <kayyagari@apache.org> wrot=
e:
> On Tue, Aug 16, 2011 at 7:06 PM, Emmanuel Lecharny <elecharny@gmail.com> =
wrote:
>> On 8/16/11 3:22 PM, Kiran Ayyagari wrote:
>>>
>>> On Tue, Aug 16, 2011 at 6:45 PM, Stefan Seelmann<seelmann@apache.org>
>>> =A0wrote:
>>>>
>>>> On Tue, Aug 16, 2011 at 2:22 PM, Kiran Ayyagari<kayyagari@apache.org>
>>>> =A0wrote:
>>>>>>
>>>>>> One solution would be to store two more elements in the ParentIdAndR=
dn
>>>>>> 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 hierarc=
hy
>>>>>> 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 oneLe=
vel
>>>>>> 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 th=
at
>> 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=E9charny
>> www.iktek.com
>>
>>
>
>
>
> --
> Kiran Ayyagari
>