Hi Jeff,
From what I understood, iBatis is implemented like that:
- let's assume that we will always have a transaction so make
connection.setAutoCommit("false");
- if there is a transaction ideed (an insert, update, or delete has been
performed) than make connection.commit() at the end
- if not, let the connection as is (with setAutoCommit("false"))
... please correct me if I am wrong.
For me, it is a very strange behaviour ... more naturally would be:
- if I am starting a transaction (or I am willing to use a transaction),
make connection.setAutoCommit("false");
- otherwise, let the connection with autoCommit=true, as it is default
I agree that current iBatis implementation works in many environments BUT I
do not feel it clean and natural ... I do think that Websphere "feature" (if
a connection that is returned to the pool has autoCommit=false and no
connection.commit() was performed then do something -- "do something" is
Websphere configurable, by default Websphere makes a rollback() --) is a
good one and iBatis acts a little bit strange in this context.
Thank you,
Cornel
----- Original Message -----
From: "Jeff Butler" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, July 07, 2006 3:38 PM
Subject: Re: autoCommit
As I said, iBATIS is trying to avoid extra commits when they are not
needed. So iBATIS sets auto commit to false, and then will commit the
transaction if an insert, update, or delete has been performed. This
works
in many environments, but not WebSphere.
This is precisely why there are options on the transaction managers -
because all the different environments work a little differently.
I added some information about this in the developer guide a few weeks
ago.
Jeff Butler
On 7/7/06, Cornel Antohi <[EMAIL PROTECTED]> wrote:
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 why iBatis is ALWAYS making:
connection.setAutoCommit(false);
What is the reason?
Thank you,
Cornel
----- Original Message -----
*From:* Jeff Butler <[EMAIL PROTECTED]>
*To:* [email protected]
*Sent:* Friday, July 07, 2006 3:09 PM
*Subject:* Re: autoCommit
iBATIS is trying to avoid extra commits when they are not needed, but
that
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
On 7/7/06, Cornel Antohi <[EMAIL PROTECTED]> wrote:
>
> 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:
> <
> transactionManager type="JDBC" *commitRequired="true" *>
> and iBatis will perform a commit() at the end (see SqlMapConfigParser
> and TransactionManager classes):
>
> txManager.setForceCommit(
> "true".equals(attributes.getProperty( "commitRequired"))); ...
> if
> (session.isCommitRequired() || forceCommit ) { trans.commit();
> session.setCommitRequired(
> *false*); }
>
> My question is: why should I use "commitRequired=true" even if I am
> executing a simple SELECT statement ? I feel that this
> "commitRequired=true"
> is a workaround to a problem generated by wrong initialization of the
> JdbcTransaction!
>
> Thank you,
> Cornel
>
