From dev-return-39872-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sat Dec 24 19:34:16 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 434F69D8F for ; Sat, 24 Dec 2011 19:34:16 +0000 (UTC) Received: (qmail 49714 invoked by uid 500); 24 Dec 2011 19:34:16 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 49668 invoked by uid 500); 24 Dec 2011 19:34:16 -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 49661 invoked by uid 99); 24 Dec 2011 19:34:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Dec 2011 19:34:16 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@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; Sat, 24 Dec 2011 19:34:09 +0000 Received: by wibhi5 with SMTP id hi5so4762819wib.37 for ; Sat, 24 Dec 2011 11:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Vymu8DnGjopi6FDsorZ89CDPyI13SV/RSlO1LAOGV2g=; b=YqgY/JFpXjBearMCbo4d60W+rH9Jb3Gm5iLvWgPZ1m+hA/3eHuEZlzPvATbCvfJqP1 hWnNKwj/ASTA5b9/+g9wceOkXRp8BKPd/e4JnBA8WTEk/gPR+jo4X/laLOMktTzvcFGN RDYTuHWXApLw0zCfP7qnGOtth8KgewW9ahzZA= MIME-Version: 1.0 Received: by 10.180.8.229 with SMTP id u5mr42212133wia.9.1324755228457; Sat, 24 Dec 2011 11:33:48 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.180.103.97 with HTTP; Sat, 24 Dec 2011 11:33:48 -0800 (PST) In-Reply-To: <4EF5D8F7.3020603@gmail.com> References: <4EF5D8F7.3020603@gmail.com> Date: Sat, 24 Dec 2011 21:33:48 +0200 X-Google-Sender-Auth: 3nfTFEai_hyrXEj3valS32zF9HQ Message-ID: Subject: Re: Txns & tests heads up From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=f46d044289eace7b7704b4db9c78 --f46d044289eace7b7704b4db9c78 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 24, 2011 at 3:51 PM, Emmanuel Lecharny wrote: > Hi, > > I'm fixing tests in core-integ, and so far, I still have some issues in > uathz (SearchAuthorizationIT) and in schema. All the other tests are now > passing. > > I have moved the txns borders into the OperationManager, and for searches, > the cursor commit or abort the txn in the close() and close(exception) > methods. > > Why is the OM better than the CoreSession? Just curious what made you choose this route. Forgive me if this was discussed in an earlier email. > I think we should find a way to implicitely commit or abort the txns even > if the user does not close() the cursors, otherwise it might be extremely > painful for them. I was thinking about adding a finalaizer in the cursor to > finish the txns, but it's not a perfect solution (as it depends on the GC > to be executed. Oh please don't do this - we should be able to find a better solution I am sure. There are a myriad of reasons why this is a bad idea IMHO. We can discuss this once I settle down in one place .. .still traveling. > Damn I miss the C++ explicit destuctors :/). > Something more useful would be to allow any txns to reuse an existing > txns. YES this is what we need to do for re-entry but there may need to be some configurable parameter for this. Maybe we can Skype on this to be fast and report back to the ML. > Of course, there are some drawbacks, but I think it's probably a better > approach. > > +1 -- Best Regards, -- Alex --f46d044289eace7b7704b4db9c78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Dec 24, 2011 at 3:51 PM, Emmanue= l Lecharny <ele= charny@gmail.com> wrote:
Hi,

I'm fixing tests in core-integ, and so far, I still have some issues in= uathz (SearchAuthorizationIT) and in schema. All the other tests are now p= assing.

I have moved the txns borders into the OperationManager, and for searches, = the cursor commit or abort the txn in the close() and close(exception) meth= ods.


Why is the OM better than the CoreSess= ion? Just curious what made you choose this route. Forgive me if this was d= iscussed in an earlier email.


I think we should find a way to implicitely commit or abort the txns even i= f the user does not close() the cursors, otherwise it might be extremely pa= inful for them. I was thinking about adding a finalaizer in the cursor to f= inish the txns, but it's not a perfect solution (as it depends on the G= C to be executed.

Oh please don't do this - we should be able to find= a better solution I am sure. There are a myriad of reasons why this is a b= ad idea IMHO. We can discuss this once I settle down in one place .. .still= traveling.
=A0
Damn I miss the C++ explicit d= estuctors :/).
Something more useful would be to allow any txns to reuse an existing txns.=

YES this is what we need to do for re-ent= ry but there may need to be some configurable parameter for this.

Maybe we can Skype on this to be fast and report back t= o the ML.
=A0
Of course, ther= e are some drawbacks, but I think it's probably a better approach.


+1

<= br>
--
Best Regards,
-- Alex

--f46d044289eace7b7704b4db9c78--