LocalTransactionContainment

I am a newbie at Spring-DAO. I am using Websphere 5.1 and DB2Connect jdbc driver for DB2 and I keep getting the following error when I used JdbcTemplate. Any ideas:

[8/17/04 16:24:44:923 CDT] 5784be0c SharedPool I J2CA0086W: Shareable connection MCWrapper id 6f5f7e1e Managed connection com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImp l@48b87e1e State:STATE_TRAN_WRAPPER_INUSE
from resource jdbc/db2t was used within a local transaction containment boundary.
[8/17/04 16:24:45:324 CDT] 5784be0c LocalTranCoor E WLTC0033E: Resource jdbc/db2t rolled back in cleanup of unresolved LocalTransactionContainment.
[8/17/04 16:24:45:377 CDT] 5784be0c LocalTranCoor E WLTC0032E: One or more resources rolled back. An unresolved LocalTransactionContainment had an unresolved action of rollback.
[8/17/04 16:24:45:408 CDT] 5784be0c WebAppTransac E WTRN0043I: LocalTransaction rolled-back due to setRollbackOnly.
[8/17/04 16:24:45:514 CDT] 5784be0c WebGroup E SRVE0026E: [Servlet Error]-[LocalTransaction rolled-back due to setRollbackOnly]: com.ibm.ws.LocalTransaction.RolledbackException
at com.ibm.ws.LocalTransaction.LocalTranCoordImpl.cle anup(LocalTranCoordImpl.java:1073)
at com.ibm.ws.webcontainer.webapp.WebAppTransactionCo llaborator.postInvoke(WebAppTransactionCollaborato r.java:249)


rdevet

Please post showing the PlatformTransactionManager implementation you're using (e.g. JtaTransactionManager). My guess is that you may be trying to use DataSourceTransactionManager (which does local transactions) with a JTA-aware DataSource which WebLogic expects to be involved only in global transactions.

I figured out my problem. Our JDBC driver settings (DB2Connect) is set to autocommit=0 (false).
When I set it autocommit=1 (true) then my program works fine. Since I am only doing reads, this would work for me. Unfortunately, I don't have the luxury of changing the autocommit setting in the production environment. So is there anyway that I can easily issue a commit() from JdbcTemplate?

This seems to work but it is not in the spirit of Spring:
try {
getConnection().commit();
} catch (SQLException e) {
e.printStackTrace();
}

Autocommit _should_ be false, in normal usage. You want the transaction manager ot cimmit. I realize it's working for you with it set to true, but that's not really a solution, in that your problem is still there with it set properly...

Colin

The autocommit applies only to implicit transactions. For some databases, every SELECT starts an implicit tx. So that setting tells the db weather or not to commit the implicit tx. For _explicit_ tx, I agree with you about the tx manager. But if I am only doing SELECTS do I still need the overhead of the tx manager?

rdevet.

No, if all you need to do is read data and don't need to worry about concurrent access by other people, you don't have to be transacitonal. My point was that ieven with autocommit=true resolving the problem for this particular use-case, you don't really have a working environment for a more general use-case where you need transactions.

I recommend to execute all your read operations within Spring-managed transactions in that case. I guess all that WebSphere complains about here is that you executed statements on a non-autoCommit Connection and didn't call commit or rollback: So you should be able to leave autoCommit=false and demarcate Spring transactions for your read operations, which will properly commit or rollback on completion (without any custom transaction management involved).

Juergen