Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 55239 invoked from network); 28 Apr 2006 10:16:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Apr 2006 10:16:50 -0000 Received: (qmail 53158 invoked by uid 500); 28 Apr 2006 10:16:25 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 53105 invoked by uid 500); 28 Apr 2006 10:16:24 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 53089 invoked by uid 99); 28 Apr 2006 10:16:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Apr 2006 03:16:24 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of bojan@rexursive.com designates 203.171.74.242 as permitted sender) Received: from [203.171.74.242] (HELO beauty.rexursive.com) (203.171.74.242) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Apr 2006 03:16:22 -0700 Received: from coyote.rexursive.com (coyote.rexursive.com [172.27.0.22]) by beauty.rexursive.com (Postfix) with ESMTP id 3CAD82566B7 for ; Fri, 28 Apr 2006 20:16:00 +1000 (EST) Subject: Re: [PATCH]: Introduce apr_dbd_transaction_rollback From: Bojan Smojver To: dev@apr.apache.org In-Reply-To: <200604281031.08602.nick@webthing.com> References: <20060428145749.jh5cf8eqsw8osoc0@www.rexursive.com> <200604281031.08602.nick@webthing.com> Content-Type: text/plain Date: Fri, 28 Apr 2006 20:16:02 +1000 Message-Id: <1146219362.6367.3.camel@coyote.rexursive.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote: > What's missing is the option to rollback even when successful. > In principle, a "rollback" argument to transaction_end would be > a better way to accomplish this. What level of version bump would > we need to introduce that? Given that this would break binary compatibility, it would have to be done in 2.x. The "new function approach" could be done for 1.3. -- Bojan