Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 25677 invoked from network); 7 Jul 2006 12:33:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Jul 2006 12:33:06 -0000 Received: (qmail 13088 invoked by uid 500); 7 Jul 2006 12:33:05 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 12761 invoked by uid 500); 7 Jul 2006 12:33:03 -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 12750 invoked by uid 99); 7 Jul 2006 12:33:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Jul 2006 05:33:03 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [217.156.99.222] (HELO mail.kepler-rominfo.com) (217.156.99.222) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Jul 2006 05:33:02 -0700 Received: from mail.kepler-rominfo.com (mail.kepler.ro [127.0.0.1]) by localhost (Postfix) with ESMTP id 53FADB76 for ; Fri, 7 Jul 2006 15:32:28 +0300 (EEST) Received: from coan (unknown [192.168.16.13]) by mail.kepler-rominfo.com (Postfix) with SMTP id 3B716B6D for ; Fri, 7 Jul 2006 15:32:28 +0300 (EEST) Message-ID: <006101c6a1c1$711290c0$0d10a8c0@coan> From: "Cornel Antohi" To: References: <003a01c6a1b4$ede23d10$0d10a8c0@coan> Subject: Re: autoCommit Date: Fri, 7 Jul 2006 15:32:42 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C6A1DA.96562BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) 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_005E_01C6A1DA.96562BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeff, In order to avoid extra commits, shouldn't iBatis do: connection.setAutoCommit(true); ? But iBatis always make connection.setAutoCommit(false) which means that we = have to perform a connection.commit() at the end ... I do not understand wh= y iBatis is ALWAYS making: connection.setAutoCommit(false); What is the reason? Thank you, Cornel ----- Original Message -----=20 From: Jeff Butler=20 To: user-java@ibatis.apache.org=20 Sent: Friday, July 07, 2006 3:09 PM Subject: Re: autoCommit iBATIS is trying to avoid extra commits when they are not needed, but tha= t doesn't play well with WebSphere. This is a "feature" of WebSphere. See= here: http://opensource.atlassian.com/confluence/oss/display/IBATIS/Environment= +Specific+Information Other transaction managers are a little looser in their implementations. In other words - that's just the way it is. Jeff Butler =20 On 7/7/06, Cornel Antohi wrote:=20 Hi, I have found in com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransacti= on class, init method, the following lines of code: // AutoCommit if (connection .getAutoCommit()) {=20 connection.setAutoCommit(false );=20 } 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 war= ning 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 becau= se it seems to be in a transaction !!! One solution found on Internet is to setup in sql-map-config: < transactionManager type=3D"JDBC" commitRequired=3D"true" >=20 and iBatis will perform a commit() at the end (see SqlMapConfigParser a= nd TransactionManager classes): txManager.setForceCommit( "true".equals(attributes.getProperty( "commitRequired")));=20 ... if (session.isCommitRequired() || forceCommit ) {=20 trans.commit(); session.setCommitRequired( false);=20 } My question is: why should I use "commitRequired=3Dtrue" even if I am e= xecuting a simple SELECT statement ? I feel that this "commitRequired=3Dtru= e" is a workaround to a problem generated by wrong initialization of the Jd= bcTransaction!=20 Thank you, Cornel ------=_NextPart_000_005E_01C6A1DA.96562BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
 
In order to avoid extra commits, shouldn't= iBatis=20 do:
 
connection.setAutoCommit(true);=20 ?
 
But iBatis always make=20 connection.setAutoCommit(false) which means that we have t= o=20 perform a connection.commit() at the end ... I do not understand why i= Batis=20 is ALWAYS making:
connection.setAutoCommit(false);
 
What is the reason?
 
Thank you,
Cornel
----- Original Message -----
Fro= m:=20 Je= ff=20 Butler
Sent: Friday, July 07, 2006 3:09 P= M
Subject: Re: autoCommit

iBATIS is trying to avoid extra commits when they are not needed, bu= t=20 that doesn't play well with WebSphere.  This is a "feature" of=20 WebSphere.  See here:
 
 
Other transaction managers are a little looser in their=20 implementations.
 
In other words - that's just the way it is.
 
Jeff Butler

 
On 7/7/06, Cor= nel=20 Antohi <cantohi@kepler-rominfo.com= >=20 wrote:=20
Hi,
 
I have found in com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction class, init method, the following lines of=20 code:
 
//=20 AutoCommit
if (connection=20 .getAutoCommit()) {=20
    connection.setAutoCommit(false );=20
}
 
I do not understand why should it be set to "fa= lse" by=20 default, even I am running simple SELECT statements !
 
Using Websphere as application server, I am rec= eiving=20 the following warning messages after each database call:
[7/7/06 13:40:41:111 EEST] 00000026 LocalTranCo= or=20 W   WLTC0032W: One or more local transaction resources were r= olled=20 back during the cleanup of a LocalTransactionContainment.
 
and sometimes errors like Websphere cannot clea= nup 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(=20 "commitRequired")));=20
...
if
(session.isCommitRequired() || forceCommit ) = {=20
   =20 trans.commit();
   =20 session.setCommitRequired(
false);=20
}
 
My question is: why should I use "commitRequire= d=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
<= /DIV>
= ------=_NextPart_000_005E_01C6A1DA.96562BD0--