From dev-return-39891-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Dec 28 16:07:20 2011 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 947A29BD4 for ; Wed, 28 Dec 2011 16:07:20 +0000 (UTC) Received: (qmail 44764 invoked by uid 500); 28 Dec 2011 16:07:20 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 44721 invoked by uid 500); 28 Dec 2011 16:07:20 -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 44713 invoked by uid 99); 28 Dec 2011 16:07:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Dec 2011 16:07:20 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 209.85.212.178 as permitted sender) Received: from [209.85.212.178] (HELO mail-wi0-f178.google.com) (209.85.212.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Dec 2011 16:07:13 +0000 Received: by wibhi5 with SMTP id hi5so7325147wib.37 for ; Wed, 28 Dec 2011 08:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l9qVtJmJqSAWybA2h4ODIzltxgPRZkkeY2zCGcpSkEQ=; b=uYIjFmEjypcJI9/NjLUrSgSYFmy8vVw8Aw3lW7TeBTUGkrqAmLOGLKoveZfmPh4ihZ VmA7kep4MM87dqrl1GpVxSk8T7qvf1vMnZTrILgX/+CDpVoyhxZ0cz3I/XEDFUM3DrPX QoQW9KQRLr2POUVDbvwcYaYvSvi6rKJV3o0x8= Received: by 10.180.83.69 with SMTP id o5mr71615201wiy.1.1325088412631; Wed, 28 Dec 2011 08:06:52 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local ([90.84.144.38]) by mx.google.com with ESMTPS id w8sm75616077wiz.4.2011.12.28.08.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Dec 2011 08:06:51 -0800 (PST) Message-ID: <4EFB3E8C.40005@gmail.com> Date: Wed, 28 Dec 2011 17:06:36 +0100 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: Storing the txn nto each operationContext References: <4EF7432B.8070409@gmail.com> <4EF766AF.4010102@apache.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/25/11 8:27 PM, Selcuk AYA wrote: > On Sun, Dec 25, 2011 at 8:08 PM, Emmanuel Lécharny wrote: >> On 12/25/11 5:58 PM, Selcuk AYA wrote: >>> On Sun, Dec 25, 2011 at 5:37 PM, Emmanuel Lecharny >>> wrote: >>>> Hi, >>>> >>>> I started to play with this concept. The idea is to able to have >>>> encapsulated operations using their own transactions, following these >>>> rules >>>> : >>>> >>>> 1) if there is another pending Read transaction, and if the new operation >>>> is >>>> read only, then reuse the pending transaction >>>> 2) if there is another pending Read transaction, and if the new operation >>>> is >>>> ReadWrite, then create a new transaction >>>> 3) if there is another ReadWrite transaction, then generate an error (we >>>> can't have such a case) >>>> >>>> That means we can have a non limited number of encapsulated RO txns, but >>>> we >>>> can't have more than one RW txn running. >>>> >>>> RO(RO(RO...(RO)...))) is possible >>>> RO(RO(RW))) is possible >>>> RO(RO(RW(RO is not possible >>>> RW(RO is not possible >>>> RW(RW is not possible >>>> >>>> In order to implement that, we need to add one thing : >>>> - a nbRef in readOnly transactions, which will be incremented and >>>> decremented as soon as we add new RO txns or abort/commit txns >>>> >>>> Is that enough ? >>> this is also a reply to you previous email. >>> >>> I suggest we use a txn per operation but we do not have to store the >>> txn context pointer in operation context. We can still have the thread >>> context stored in thread local variable but we also store a TxnHandle >>> ref in EntryFilteringCursor. And we do something like this: >>> >>> next() >>> { >>> get txn handle stored in the cursor and set it as the thread local >>> variable. >>> do the next >>> unset the thread local variable. >>> } >> >> In fact, as each operation except Search are atomic, I don't know if it's >> useful to store the txn in the thread local variable. Regarding the search, >> we just have to store the txn in the cursor, so we don't have to store it >> into the thread local variable either. >> >> Another reason we might not want to use thread local variable is that an >> abandon operation will have to close a txn, and that means grab the txn from >> another thread.It's easier to get the existing cursor, and close the cursor. >> (FYI, we may have more than one thread per session, just in order to be able >> to handle an AbandonRequest) >> >> Unless I'm missing something, of course ! > There are different layers and different classes that call into txn > layer and txn layer conveniently gets the current txn from the thread > local variable. If you change this you will have to pass around txn > context. Not impossible but quite a number of changes. The pb is that if you don't pass teh txn, then you have the reverse issue : switching the threadLocal content each time you call the txn layer. IMO (and after having played around with the code), it's probably better to pass the txn we have stored. I'm still evaluating this option. > > But AbondonRequest is really a problem. I see that the abandon request > listener for search just closes the cursor but at that time the txn > might be executing and we cannot just abort an executing txn. If we consider that abandon requests are just good for Search operations, then what it does is simply to switch a flag in the OperationContext, flag which is tested when the next() method is called : public boolean next() throws Exception { if ( getOperationContext().isAbandoned() ) { LOG.info( "Cursor has been abandoned." ); close(); throw new OperationAbandonedException(); } As the close() is called, we should be safe here. More to come later (after the dinner) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com