Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 69538 invoked from network); 25 Jan 2007 18:23:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Jan 2007 18:23:56 -0000 Received: (qmail 19841 invoked by uid 500); 25 Jan 2007 18:23:59 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 19831 invoked by uid 500); 25 Jan 2007 18:23:59 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 19820 invoked by uid 99); 25 Jan 2007 18:23:59 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jan 2007 10:23:59 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of clinton.begin@gmail.com designates 64.233.184.238 as permitted sender) Received: from [64.233.184.238] (HELO wr-out-0506.google.com) (64.233.184.238) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jan 2007 10:23:50 -0800 Received: by wr-out-0506.google.com with SMTP id 55so634753wri for ; Thu, 25 Jan 2007 10:23:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uphKI7Q7lhQZYk9AYX+cqb2MpA3lpEJUXVq25FbFudyRQszm/6K5DJtS30WzYPWBLXeSEwxX6WetcIvE7Wf/qozF0F/fBfa2z03Y9UBs2FwKmMcwQj08xx9D9QgG4y5vS3b2IXv93EwP5TeXjaVTYLhO/Xi9cqfPJp0uwu8KWGQ= Received: by 10.90.50.1 with SMTP id x1mr2687163agx.1169749409662; Thu, 25 Jan 2007 10:23:29 -0800 (PST) Received: by 10.114.135.7 with HTTP; Thu, 25 Jan 2007 10:23:29 -0800 (PST) Message-ID: <16178eb10701251023x5f6d39a7kc150b31b4594d62d@mail.gmail.com> Date: Thu, 25 Jan 2007 11:23:29 -0700 From: "Clinton Begin" To: user-java@ibatis.apache.org Subject: Re: Autocommit not properly handled in Ibatis. In-Reply-To: <017f01c740ad$52035b20$0d10a8c0@coan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003601c73e45$5eac8aa0$0d10a8c0@coan> <16178eb10701220909x2c3c7fd0jcdb99b825e0dd7e1@mail.gmail.com> <46d2280d0701230211w5d80b8dob7cbb135dff60659@mail.gmail.com> <001201c74053$2aa5f150$0d10a8c0@coan> <46d2280d0701250721u3e40d0b7w21d56d2ea9044bde@mail.gmail.com> <011401c7409e$9bec3ef0$0d10a8c0@coan> <16178eb10701250855q45945e35pe3cbbc5ca176173d@mail.gmail.com> <017f01c740ad$52035b20$0d10a8c0@coan> X-Virus-Checked: Checked by ClamAV on apache.org No, absolutely not. It will either make one start/commit/end per method call to SQLClient (if you don't start a transaction) or just one that you call explicitly. The only exception is if you're using Lazy Loading, but that's totally within your control. iBATIS always attempts to use the most efficient transaction scope possible. So you shouldn't have to worry about it. Clinton On 1/25/07, Cornel Antohi wrote: > Hi Clinton, > > Murphy's law is validated again: I am using Oracle :( > > If I am using in a method N SELECT queries with commitRequired=true, iBATIS > makes N commit() (one at the end of each query), right? Do you have any clue > / recommendation how to minimize this overhead using iBATIS + Oracle? > > Thank you, > Cornel > > > ----- Original Message ----- > From: "Clinton Begin" > To: > Sent: Thursday, January 25, 2007 6:55 PM > Subject: Re: Autocommit not properly handled in Ibatis. > > > > In hindsight I wish I had made the default commitRequired=true... > > > > I believe the only database that really suffers from unecessary > > commits is Oracle. The other RDBMS are actually pretty good about not > > incurring additional overhead, and in fact Sybase drivers I've used > > demand that either commit or rollback be called in all cases except > > AutoCommit of course. > > > > Anyway, unless you're using Oracle, feel free to make your lives > > easier by just setting commitRequired=true.. :-) > > > > Clinton > > > > On 1/25/07, Cornel Antohi wrote: > >> > >> > >> Hi Koka, > >> > >> In case of iBATIS commitRequired=false, if you execute SELECT statements, > >> they are grouped into a transaction that "is terminated by a call to > >> either > >> the method commit or the method rollback" ... because iBATIS never calls > >> commit() or rollback() it means that iBATIS do not handle properly the > >> transactions, right? > >> > >> > >> Thank you, > >> Cornel > >> > >> > >> ----- Original Message ----- > >> From: Koka Kiknadze > >> To: user-java@ibatis.apache.org > >> Sent: Thursday, January 25, 2007 5:21 PM > >> Subject: Re: Autocommit not properly handled in Ibatis. > >> > >> > >> > >> > > >> > > >> > In iBATIS SELECT case, no commit or rollback is executed ... > >> > > >> > Question: > >> > How do you interpret this fact? > >> > > >> > >> Not sure what kind of interpretation you ask for ;) > >> > >> Again, if the code looks like (you can leave out startTransaction / > >> commitTransaction in defaultAutocommit=true mode, as iBatis will > >> internally > >> add those for any SQL statement) : > >> sqlMapClient.startTransaction(); > >> sqlMapClient..queryFor...(); > >> sqlMapClient.commitTransaction(); > >> > >> Underlying connection object's commit() method is NOT called if > >> commitRequired property is set to false (it would get called if it were > >> insert/update etc.), and vice versa - connection.commit() IS called if > >> commitRequired = true. Setting commitRequired =false saves extra commit > >> calls when no data has changed. > >> > >> > >> > >> > >> > >> > >> > >