Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 23711 invoked from network); 27 Nov 2008 22:47:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Nov 2008 22:47:03 -0000 Received: (qmail 67317 invoked by uid 500); 27 Nov 2008 22:47:10 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 67306 invoked by uid 500); 27 Nov 2008 22:47:10 -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 67295 invoked by uid 99); 27 Nov 2008 22:47:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Nov 2008 14:47:10 -0800 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=HTML_MESSAGE,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kiknadze@gmail.com designates 72.14.220.155 as permitted sender) Received: from [72.14.220.155] (HELO fg-out-1718.google.com) (72.14.220.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Nov 2008 22:45:42 +0000 Received: by fg-out-1718.google.com with SMTP id d23so767652fga.32 for ; Thu, 27 Nov 2008 14:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=nf8tIvkf6WasnQTYbMhwpNYh22EATWzFHDGYdK3dJgc=; b=erILJJdZtaaGtrWc+iaW+KklN2N+z9zRZM/154hlXrP5eTE/NDTyDUyEC0ndEJ/inA WUpybDAy7hnRsc/fXHEYe+v71laa9VKAU+QmxPif0/ozDY08XYA10GlmT2ak/grZmQ2S ybwLwmpGmObWelTNXTmxvU3EVZcmuMAiiwXNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=XYZAJfJ+bEL8IOHKZre63aMLC41VD63q+3oe7AmJhZt0eAO05jSD2XQFsPf4FgcD8R 381iaOOxgxJRIonfWWUwFV6BNsUpIIEn9sjXL18ZeAoWCpL8Bv9LsHRNxHgLRXQkUOfz 0+ySCAqHBofx38BViXrEks/YaZ023NofAuVn0= Received: by 10.86.76.20 with SMTP id y20mr4914845fga.37.1227825977519; Thu, 27 Nov 2008 14:46:17 -0800 (PST) Received: by 10.86.77.20 with HTTP; Thu, 27 Nov 2008 14:46:17 -0800 (PST) Message-ID: <536e8800811271446k4f622944i7ef65f453195ba8a@mail.gmail.com> Date: Thu, 27 Nov 2008 17:46:17 -0500 From: "Nicholoz Koka Kiknadze" To: user-java@ibatis.apache.org Subject: Re: Question on iBatis Implicit Transactions ? In-Reply-To: <20694266.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2621_16737743.1227825977509" References: <20694266.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_2621_16737743.1227825977509 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2b) Scenario: copy/pasting from manual: __________________________ The element also allows an optional attribute * commitRequired* that can be *true* or *false*. Normally iBATIS will not commit transactions unless an insert, update, or delete operation has been performed. *This is true even if you explicitly call the commitTransaction(= ) method*. This behavior creates problems in some cases. If you want iBATIS t= o always commit transactions, even if no insert, update, or delete operation has been performed, then set the value of the *commitRequired* attribute to *true*. Examples of where this attribute is useful include: 1. If you call a stored procedures that updates data as well as returning rows. In that case you would call the procedure with the queryForList() operation =96 so iBATIS would not normally commit the transaction. But t= hen the updates would be rolled back. _________________________ So yes, iBatis will rollback. 2a scenario: if you forget to call endTransaction iBatis will do nothing an= d sooner or later your connection pool will get exhausted. Copy/pasting again= : _______________ Notice how endTransaction() is called regardless of an error. This is an important step to ensure cleanup. The rule is: if you call startTransaction() be absolutely certain to call endTransaction() (whether you commit or not). _______________ 1a: Again some little copy/paste ;) ___________ Although using explicit transactions is very highly recommended, there is a simplified semantic that can be used for simple requirements (generally read-only). If you do not explicitly demarcate transactions using the startTransaction(), commitTransaction() and endTransaction() methods, they will all be called automatically for you whenever you execute a statement outside of a transactional block ____________ Not sure, but think COMMIT_REQUIRED applies here also, i.e. iBatis will rollback after any SELECT statement unless COMMIT_REQUIRED=3Dtrue Try to use docs from SVN, nowadays they contain far more info than they use= d to couple of years ago ;) On Tue, Nov 25, 2008 at 10:43 PM, mfs wrote: > > Hello Guys, > > I have got a couple of questions relating to iBatis starting out implicit > trasactions..Let me add that i am using iBatis "JDBC" TransactionManager. > > Please comment/correct me on the following understanding, given > COMMITREQUIRED=3D"TRUE" : > > 1a) iBatis implicitly starts a transaction if one isn't explicitly starte= d > ? > If that is true would iBatis commit the transaction in the end (given we > never started one mistakenly or otherwise and hence not > committing/rolling-back) ? > 2a) Second Scenario. We do start a transaction but don't explicitly do a > commit in the end. Would iBatis do the commit for you, given no exception= s > got raised OR it would just rollback the transaction ? > 2b) Relating to the above scenario, I read somewhere that iBatis would > rollback the transaction if it is "select" query, what if it is "select f= or > update" ? > > Thanks > > Farhan. > > > > -- > View this message in context: > http://www.nabble.com/Question-on-iBatis-Implicit-Transactions---tp206942= 66p20694266.html > Sent from the iBATIS - User - Java mailing list archive at Nabble.com. > > ------=_Part_2621_16737743.1227825977509 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2b) Scenario: copy/pasting from manual:
__________________________
=09 =09 =09 =09

The <transactionManage= r> element also allows an optional attribute commitRequired that can be true or false. Normally iBATIS will not commit transactions unless an insert, update, or delete operation has been performed. This is true even if you explicitly call the commitTransaction() method. This behavior creates problems in some cases. If you want iBATIS to always commit transactions, even if no insert, update, or delete operation has been performed, then set the value of the commitRequired attribute to true. Examples of where this attribute is useful include:


  1. If you call a sto= red =09procedures that updates data as well as returning rows. In that =09case you would call the procedure with the queryForList() operation =09=96 so iBATIS would not normally commit the transaction. But then =09the updates would be rolled back.

    =09
_________________________

So yes, iBatis will rollback.=

2a scenario: if you forget to call endTransaction iBatis will do no= thing and sooner or later your connection pool will get exhausted. Copy/pas= ting again:
_______________
=09 =09 =09 =09

Notice how endTransaction() is called regardless of an error. This is an important step to ensure cleanup. The rule is: if you call startTransaction() be absolutely certain to call endTransaction() (whether you commit or not).

_______________



1a: Again some little copy/paste ;)
___________
=09 =09 =09 =09

Although using explicit transactions is very highly recommended, there is a simplified semantic that can be used for simple requirements (generally read-only). If you do not explicitly demarcate transactions using the startTransaction(), commitTransaction() and endTransaction() methods, they will all be called automatically for you whenever you execute a statement outside of a transactional block

____________

Not sure, but think COMMIT_REQUIRED app= lies here also, i.e. iBatis will rollback after any SELECT statement unless= COMMIT_REQUIRED=3Dtrue


Try to use docs from SVN, nowadays they contain far more info than they= used to couple of years ago ;)




On Tue, Nov 25, 2008 at 10:43 PM, mfs <farhan.sarwar@gmail.com> wrote= :

Hello Guys,

I have got a couple of questions relating to iBatis starting out implicit trasactions..Let me add that i am using iBatis "JDBC" Transaction= Manager.

Please comment/correct me on the following understanding, given
COMMITREQUIRED=3D"TRUE" :

1a) iBatis implicitly starts a transaction if one isn't explicitly star= ted ?
If that is true would iBatis commit the transaction in the end (given we never started one mistakenly or otherwise and hence not
committing/rolling-back) ?
2a) Second Scenario. We do start a transaction but don't explicitly do = a
commit in the end. Would iBatis do the commit for you, given no exceptions<= br> got raised OR it would just rollback the transaction ?
2b) Relating to the above scenario, I read somewhere that iBatis would
rollback the transaction if it is "select" query, what if it is &= quot;select for
update" ?

Thanks

Farhan.



--
View this message in context: = http://www.nabble.com/Question-on-iBatis-Implicit-Transactions---tp20694266= p20694266.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


------=_Part_2621_16737743.1227825977509--