|
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 -----
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:
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
|
