Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 84540 invoked from network); 8 Jul 2006 08:15:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Jul 2006 08:15:13 -0000 Received: (qmail 25762 invoked by uid 500); 8 Jul 2006 08:15:11 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 25745 invoked by uid 500); 8 Jul 2006 08:15:11 -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 25734 invoked by uid 99); 8 Jul 2006 08:15:11 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Jul 2006 01:15:11 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of j2eedodo@gmail.com designates 64.233.162.195 as permitted sender) Received: from [64.233.162.195] (HELO nz-out-0102.google.com) (64.233.162.195) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Jul 2006 01:15:09 -0700 Received: by nz-out-0102.google.com with SMTP id q3so13824nzb for ; Sat, 08 Jul 2006 01:14:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:from:to:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=NeiNH/LNPDF9cbsYUwVQ1CzZtLOFCNM7RaVOksnrDF25/7bcOU0HrWTzr8X3pUtptzFd0hRR6Ba1jcI7+p6XdWNs94ORfLCRzQhvSsjs1IPstbQ/3DZc7Wo0Am70s155VIHNfHmRG/5iQjWvdzRUQLDvvaMfdgRhBA7nWgPbbbE= Received: by 10.36.19.19 with SMTP id 19mr3396570nzs; Sat, 08 Jul 2006 01:14:48 -0700 (PDT) Received: from spring ( [222.155.98.216]) by mx.gmail.com with ESMTP id 12sm1051139nzn.2006.07.08.01.14.45; Sat, 08 Jul 2006 01:14:48 -0700 (PDT) Message-ID: <033801c6a266$98a06450$0401a8c0@spring> From: "Dodo" To: References: <003a01c6a1b4$ede23d10$0d10a8c0@coan> Subject: Re: autoCommit Date: Sat, 8 Jul 2006 20:14:52 +1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0335_01C6A2CB.2BC3F080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------=_NextPart_000_0335_01C6A2CB.2BC3F080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why not use BaseDaoiBATIS class from the Spring framework and specify transaction levels from xml file to do auto commit??=20 So no manual code is required to commit Makes life easier Sam ----- Original Message -----=20 From: Cornel Antohi=20 To: user-java@ibatis.apache.org=20 Sent: Friday, July 07, 2006 11:03 PM Subject: autoCommit Hi, I have found in = com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction class, init = method, the following lines of code: // AutoCommit if (connection.getAutoCommit()) { connection.setAutoCommit(false); } I do not understand why should it be set to "false" by default, even I = am running simple SELECT statements ! Using Websphere as application server, I am receiving the following = warning messages after each database call: [7/7/06 13:40:41:111 EEST] 00000026 LocalTranCoor W WLTC0032W: One = or more local transaction resources were rolled back during the cleanup = of a LocalTransactionContainment. and sometimes errors like Websphere cannot cleanup the connection = because it seems to be in a transaction !!! One solution found on Internet is to setup in sql-map-config: =20 and iBatis will perform a commit() at the end (see SqlMapConfigParser = and TransactionManager classes): = txManager.setForceCommit("true".equals(attributes.getProperty("commitRequ= ired"))); ... if (session.isCommitRequired() || forceCommit) { trans.commit(); session.setCommitRequired(false); } My question is: why should I use "commitRequired=3Dtrue" even if I am = executing a simple SELECT statement ? I feel that this = "commitRequired=3Dtrue" is a workaround to a problem generated by wrong = initialization of the JdbcTransaction! Thank you, Cornel ------=_NextPart_000_0335_01C6A2CB.2BC3F080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Why not use BaseDaoiBATIS class from = the Spring=20 framework
and specify transaction levels from xml = file to do=20 auto commit??
 
So no manual code is=20 required to commit
 
Makes life easier
 
Sam
----- Original Message -----
From:=20 Cornel Antohi
Sent: Friday, July 07, 2006 = 11:03=20 PM
Subject: autoCommit

Hi,
 
I have found in com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction=20 class, init method, the following lines of = code:
 
//=20 AutoCommit
if = (connection.getAutoCommit()) {
    connection.setAutoCommit(false);
}
 
I do not understand why should it be set to = "false" by=20 default, even I am running simple SELECT statements !
 
Using Websphere as application server, I am = receiving=20 the following warning messages after each database call:
[7/7/06 13:40:41:111 EEST] 00000026 = LocalTranCoor=20 W   WLTC0032W: One or more local transaction resources were = rolled=20 back during the cleanup of a LocalTransactionContainment.
 
and sometimes errors like Websphere cannot = cleanup the=20 connection because it seems to be in a transaction !!!
 
One solution found on Internet is to setup in=20 sql-map-config:
<transactionManager type=3D"JDBC"=20 commitRequired=3D"true">
 
and iBatis will perform a commit() at = the end=20 (see SqlMapConfigParser and TransactionManager = classes):
 
txManager.setForceCommit("true".equals(attributes.getProperty("commitRequired")));
...
if (session.isCommitRequired() || = forceCommit) = {
   =20 trans.commit();
   =20 session.setCommitRequired(false);
}
 
My question is: why should I use = "commitRequired=3Dtrue"=20 even if I am executing a simple SELECT statement ? I feel that this=20 "commitRequired=3Dtrue" is a workaround to a problem generated by = wrong=20 initialization of the JdbcTransaction!
 
Thank you,
Cornel
= ------=_NextPart_000_0335_01C6A2CB.2BC3F080--