Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ABD71109A1 for ; Sat, 8 Feb 2014 07:28:33 +0000 (UTC) Received: (qmail 88994 invoked by uid 500); 8 Feb 2014 07:28:32 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 88732 invoked by uid 500); 8 Feb 2014 07:28:27 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 88724 invoked by uid 99); 8 Feb 2014 07:28:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Feb 2014 07:28:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ayyagarikiran@gmail.com designates 209.85.160.45 as permitted sender) Received: from [209.85.160.45] (HELO mail-pb0-f45.google.com) (209.85.160.45) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Feb 2014 07:28:21 +0000 Received: by mail-pb0-f45.google.com with SMTP id un15so4208271pbc.4 for ; Fri, 07 Feb 2014 23:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=YV3iC9xUSyu1J9e14WGRIrPw9UDrU8XpwjhuHOM/ogw=; b=xZMiZ1xc94JeMLn4siRck6JO8X3VGIq4u9CjPEe6s8Y/iDJRwJS7dalMKu31WStB2k 5Z5PdmXRIT9skliOK1AlHoE1na9yLexyTJPHr7Z32mdc6yBa7OqSEy3I0900EeKtzuvi 7bFBAhkEst+i0eIM4EB8q8j1tgcmJdHVL37hIBpAoUxNDfGtNhCFFZUEvgztYE5vF5La LxQcAyj1zwD9sEpz8fMQob1dnLNMSOdlZlmoEJDoH7se6Wbu/QBOxhA6wy6Bg7tYptSV XQJBW4HcUiukTJ0ttLZl+TqSYhileHZCSRpTy1kaKeSl8lxZ0kt2vDYTlzChPUCCklxQ 0sUA== MIME-Version: 1.0 X-Received: by 10.68.180.66 with SMTP id dm2mr24368708pbc.143.1391844481171; Fri, 07 Feb 2014 23:28:01 -0800 (PST) Sender: ayyagarikiran@gmail.com Received: by 10.68.127.39 with HTTP; Fri, 7 Feb 2014 23:28:01 -0800 (PST) In-Reply-To: <52F51F03.1070002@gmail.com> References: <52F4B178.3080606@symas.com> <52F51F03.1070002@gmail.com> Date: Sat, 8 Feb 2014 12:58:01 +0530 X-Google-Sender-Auth: xfPUz12-DOXsplzkcUUBwVXqBrk Message-ID: Subject: Re: [Mavibot] Transaction discussion From: Kiran Ayyagari To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=047d7b5d3a64e2079104f1e00b50 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b5d3a64e2079104f1e00b50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 7, 2014 at 11:29 PM, Emmanuel L=E9charny w= rote: > Le 2/7/14 11:22 AM, Kiran Ayyagari a =E9crit : > > On Fri, Feb 7, 2014 at 3:42 PM, Emmanuel L=E9charny >wrote: > > > >> Hi, > >> > >> there are two things to consider in order to support transactions : > >> > >> - we could have automatique transaction per operation (ie, we don't ha= ve > >> to start a transaction before issuing an operation) > >> - we can also create a transaction explicitely, and use it across more > >> than one operation. > >> > >> We want to support both cases. > >> > >> +1 , IMHO implicit transaction support is a MUST > > A complex MUST... > > > >> This is not trivial, as we want to make it as easy as possible for our > >> users. Typically, how should an operation know which kind of transacti= on > >> it is dealing with ? Let's have a look at such an operation : > >> > >> insert : > >> // check if we are already into a txn > >> if (in transaction) (1) > >> then > >> process operation > >> else > >> start transaction (2) > >> process operation > >> commit operation > >> > >> so far, it seems ok, but what if another thread has started a > >> transaction *just* after the test (1) and before (2) ? This is > complicated. > >> > >> hmmm, how about using ThreadLocal, > > and not sure we need to branch based on the presence of txn handle, the > > start transaction(2) > > should always give the txn handle present in ThreadLocal > > That would work if only we were in a single thread environment... In our > case, we have no idea how many threads will try to write data in Mavibot. > > ThreadLocal is meant for multithreaded environments > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com > > --=20 Kiran Ayyagari http://keydap.com --047d7b5d3a64e2079104f1e00b50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 7, 2014 at 11:29 PM, Emmanuel L=E9charny <elecharny@= gmail.com> wrote:
Le 2/7/14 11:22 AM, Kiran Ayyagari a =E9crit= :
> On Fri, Feb 7, 2014 at 3:42 PM, Emmanuel L=E9charny &l= t;elecharny@symas.com>wrote:<= br> >
>> Hi,
>>
>> there are two things to consider in order to support transactions = :
>>
>> - we could have automatique transaction per operation (ie, we don&= #39;t have
>> to start a transaction before issuing an operation)
>> - we can also create a transaction explicitely, and use it across = more
>> than one operation.
>>
>> We want to support both cases.
>>
>> +1 , IMHO implicit transaction support is a MUST

A complex MUST...


>> This is not trivial, as we want to make it as easy as possible for= our
>> users. Typically, how should an operation know which kind of trans= action
>> it is dealing with ? Let's have a look at such an operation :<= br> >>
>> insert :
>> =A0 =A0 // check if we are already into a txn
>> =A0 =A0 if (in transaction) =A0 =A0 =A0 =A0(1)
>> =A0 =A0 =A0 =A0 then
>> =A0 =A0 =A0 =A0 =A0 =A0 process operation
>> =A0 =A0 =A0 =A0 else
>> =A0 =A0 =A0 =A0 =A0 =A0 start transaction =A0(2)
>> =A0 =A0 =A0 =A0 =A0 =A0 process operation
>> =A0 =A0 =A0 =A0 =A0 =A0 commit operation
>>
>> so far, it seems ok, but what if another thread has started a
>> transaction *just* after the test (1) and before (2) ? This is com= plicated.
>>
>> hmmm, how about using ThreadLocal,
> and not sure we need to branch based on the presence of txn handle, th= e
> start transaction(2)
> should always give the txn handle present in ThreadLocal

That would work if only we were in a single thread environment... In = our
case, we have no idea how many threads will try to write data in Mavibot.
ThreadLocal is meant for multithreaded environments

--
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com




--
Kiran Ayy= agari
http://keydap.com<= /a>
--047d7b5d3a64e2079104f1e00b50--