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 elecharny@gmail.com designates
 209.85.212.178 as permitted sender)
Message-ID: <4EF7A611.4090403@gmail.com>
Date: Sun, 25 Dec 2011 23:39:13 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
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 <dev@directory.apache.org>
Subject: Re: Storing the txn nto each operationContext
References: <4EF7432B.8070409@gmail.com>
 <CALhXAG3fCQF48-VRT2PXDhXzGkbpXUT5tro0itamYf2SLEhkQQ@mail.gmail.com>
 <4EF766AF.4010102@apache.org>
 <CALhXAG03D=f8fd9EVgT7taGLkhnnPqnk9_rbsyE6-QH1=Yp-oQ@mail.gmail.com>
In-Reply-To: 
 <CALhXAG03D=f8fd9EVgT7taGLkhnnPqnk9_rbsyE6-QH1=Yp-oQ@mail.gmail.com>
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<elecharny@apache.org>  wrote:
>> On 12/25/11 5:58 PM, Selcuk AYA wrote:
>>> On Sun, Dec 25, 2011 at 5:37 PM, Emmanuel Lecharny<elecharny@gmail.com>
>>>   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.
Sure. This is not a choice to make without balancing pros and cons. As I 
said in another mail, I think it's better to keep using ThreadLocal atm.
>
> 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. I have a
> question about abandonable requests in general. How do you handle
> freeing resources related to Requests in a clean way? As far as I know
> similar situations are usually handled like this: Lets say we have a
> Disk and we want to close it because of a request received from a side
> channel. Then normal user threads do this:
>
> grab disk from a common table increment ref count
> check if disk is closed and return an error if it is.
> grab resources
> use disk
> decrement ref count
>
>
> When close request from the side channel is received:
> remove disk from global table
> mark it as closed
> wait until ref count drops to zero
> then free resources and delete disk.
>
> So resources are freed only after we make sure no user uses them.
> Currently, is there a way to close the cursor only after making sure
> that no thread will use the cursor to do search? We can abort the txn
> related to the cursor only after making sure that no thread is
> executing it.

The abandonRequest, as we implemented it, has visible two effects (from 
the users POV) :
- for search requests, it stops the sending of entries. The 
SearchResultDone is never sent too.
- for any other request, it does nothing, as each operation is atomic 
and immediate.

That means we don't respect the letter of the specification for requests 
which are not searches, but this is not really a big deal.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com