WebSphere LocalTransActionContainment conflict

[ptah]

When I run unit tests for a JtaTransaction manager managed tx enabled system from a servlet I get the following error the first time i run the servlet only:
"Cannot start a global transaction. A LocalTransactionContainment is already active with work."

Every time thereafter the servlet runs with no error [ and my unit tests pass :) ]. I've played around with the localtransaction settings in the ibm-web-ext.xmi file, but nothing seems to work.

[Rod Johnson]

You're sure you haven't started any local transactions using the JDBC transaction API or the like? And that no third-party code is doing so?

[ptah]

I am only using spring transactions, I think websphere automatically starts the local transaction. I need to know how to turn it off or make it work with spring transaction.

[clandestino]

I have the same problem. Have you found any solution ?

[clandestino]

A precision : my application is build with Spring. I use declarative transaction with WebSphereTransactionManagerFactoryBean.

When the method off my bean is executed in an MDB, everything is fine. But when the execution is done in a servlet, I have the following exception :

Cannot start a global transaction. A LocalTransactionContainment is already active with work.

Thank for your Help.

[ptah]

Unfortunately not...

[ekoeler]

We had the same issue; it turned out to be a problem with the Oracle 9i drivers we were using. Once we upgraded to 9.2.0.8.0, the issue went away completely.

[browncow]

Just for those who have had a similar issue, upgrading to the Oracle JDBC driver version 9.2.0.8.0 worked for us too.

It was odd to me that we were initiating a call to DB2 on the same server. Spring was handling JTA transactions for us, so my guess is that it was prepping all the other datasources for a JTA transaction, but Oracle didn't want to play along.

What is even odder is that we had been using that old Oracle driver for over a year now with no issues, but I recently upgraded to Spring 2.0.2 and moved to applying transactions with the new <tx:..> tags in the applicationConfig files. Perhaps there was some changes to how transactions are being applied in the new Spring code.

Nonetheless, the Oracle driver upgrade did the trick. Thanks for the help all.

Colby

[pra2464]

This resolution still helps!