File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Websphere and the fly likes Datasource rollback in WAS6.0 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Products » Websphere
Bookmark "Datasource rollback in WAS6.0" Watch "Datasource rollback in WAS6.0" New topic

Datasource rollback in WAS6.0

gaurav kumar

Joined: Apr 20, 2006
Posts: 16
Hi all,
i have an application which has been running on WAS5.0. Now we are migrating it to WAS6.0, but it is throwing datasource rollback exception.
All the properties are same as they are on WAS5.0.
Could there be any property which might have forgotten to set??
The concerned log is as under:

[9/6/06 19:41:09:625 IST] 00000072 WSRdbDataSour I DSRA8203I: Database product name : Oracle
[9/6/06 19:41:09:641 IST] 00000072 WSRdbDataSour I DSRA8204I: Database product version : Oracle9i Enterprise Edition Release - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release - Production
[9/6/06 19:41:09:641 IST] 00000072 WSRdbDataSour I DSRA8205I: JDBC driver name : Oracle JDBC driver
[9/6/06 19:41:09:688 IST] 00000072 WSRdbDataSour I DSRA8206I: JDBC driver version :
[9/6/06 19:41:09:688 IST] 00000072 WSRdbDataSour I DSRA8208I: JDBC driver type : ""
[9/6/06 19:41:09:734 IST] 00000072 SystemOut O >> createProductLanguageHashMap
[9/6/06 19:41:09:734 IST] 00000072 LocalTranCoor W WLTC0033W: Resource jdbc/CommonEntitiesDS rolled back in cleanup of LocalTransactionContainment.
[9/6/06 19:41:09:750 IST] 00000072 LocalTranCoor W WLTC0032W: One or more local transaction resources were rolled back during the cleanup of a LocalTransactionContainment.
[9/6/06 19:41:09:969 IST] 00000072 ExceptionUtil E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "remove" on bean "BeanId(CE-Ear#CE-Services.jar#EJB_CommonEntitiesService, null)". Exception data: javax.ejb.TransactionRolledbackLocalException: ; nested exception is:
RoshaniG Gopal
Ranch Hand

Joined: May 15, 2006
Posts: 180
Hi Gaurav,
This error comes when you have not commited your work in a transaction. Websphere requires your work should be comitted else it will roll back your work giving the above error. I faced the same error.
For my case,i had a common DBConnectionMgr class that used to handle all DB stuff. The executeQuery() of the method had autocommit(false). But no where(in the other classes) the work was committed. (even for a select). I changed that and explicitly commited my work and i got rid of the error.
The easiest way to debug is to check the autocommit(false) and see if it after the work is complete it is commited or not.
Hope it helps.. if not i will try to help you on that..

Regards,<br />Roshani
gaurav kumar

Joined: Apr 20, 2006
Posts: 16
many thanks roshni.....but i cant implement this solution. I have many applications deployed on the same server(in the form of EARs). the application which is showing error, i don't own other words i can't do any change in it.
Moreover the application was working fine till few days back.....its only after i introduced some new MQ Connection Factory variables that i started experiencing problems. Could it be because of these changes any how??
thank you
RoshaniG Gopal
Ranch Hand

Joined: May 15, 2006
Posts: 180
Hi Gaurav,
I believe so that the variables that you have added are responsible for it. Most of the answers available on net are for EJBs. But again I have gisted that the only reason is because of the uncommitted work.
ALso if you can send the file where you have MQ Connection variables added, we all here can have a look at that.
Please check for the following links.

Alongside this is the brief up from most of what i could collect from the net regarding this exception.
A LocalTransactionContainment is what you get in the absence of a global (XA) transaction. The message indicates that you performed some local transaction work as part of that containment scope (method or activity
session) and then did not commit. The default behaviour (controlled by unresolved-action) is to rollback any uncommited work at the end of the scope. You have a number of options:

- Explicitly commit the local transaction
connection.commit(); // after the work has been performed
- Change the data source to use auto-commit
connection.setAutoCommit(true); // before the connection is used
- Place the work within a global transaction
Context ic = new InitialContext();
UserTransaction ut =
(UserTransaction) ic.lookup("java:comp/UserTransaction");
// use connection here
- Change the unresolved-action to commit
Select the 'Servlets' tab on the deployment descriptor editor and then select the servlet in question. Under 'WebSphere Extensions' and then 'Local Transaction' set the 'Unresolved Action' to 'Commit' from the drop-down menu.

According to WAS 6 , every opened connection has to be commited (or rolledback) explicitly (didnt try autocommit) before closing. Even if all you have done with that connection is a SELECT Query. This has apparently solved the same problem I was getting. implement it and see whether it helps you.

This is a session bean, correct? Are you using container-managed, or bean-managed transactions? If container-managed, what transaction
attribute do you have on the method being called? (These settings would be in the ejb-jar.xml file.)
From the description, it looks like you're invoking a JDBC connection from within a session bean, which is fine. However, WAS is fairly good at detecting cases where the connection isn't being closed properly before the method completes, for example if it has 'dangling work' that hasn't been committed yet. These are all things that are problems if they exist; it just may be the case that WAS is detecting and pointing out these conditions where WL might *not* have been detecting them.

Finally...if this is a session bean, the beanCache stanza in the xmi file shouldn't be required in this case; that setting only applies to
entity beans. (The activateAt and loadAt settings are using to control whether the entity is using so-called "Option A", "Option B", or "Option
C" caching as described in the EJB spec.)

Iam answering my own question..The above exception happens when you use JTA transaction object of websphere and start nested transactions on allready EXISTING OPEN GLOBAL transaction.I was using ibatis framework for DAO layer and it was using JTA and starting its own new transaction inside the allready existing open blobal WAS transaction.So when it does a commit,you can see the above error coming up.I got this problem fixed by letting Ibatis come under GLOBAL WEBSPHERE transaction.


Hope it helps you..
gaurav kumar

Joined: Apr 20, 2006
Posts: 16
Hi roshni...
thank you very much for help you provided. Meanwhile i searched a solution in relation to the following error:

EJB threw an unexpected (non-declared) exception during invocation of method "remove" on bean "BeanId(CE-Ear#CE-Services.jar#EJB_CommonEntitiesService, null)". Exception data: javax.ejb.TransactionRolledbackLocalException: ; nested exception is:

I came to know that there is a patch provided in the subsequent releases of WAS6. I tried my application setup on an instance of WAS6.0.0.2(previously i was trying on WAS and it worked fine. I guess i would have to upgrade my server.
Many many thanks for the help.
I agree. Here's the link:
subject: Datasource rollback in WAS6.0
It's not a secret anymore!