connection rollback/ atomic transaction problem

[Nitin Deshmukh]

Hi,

I have a problem. I am using JSF1.1, EJB2.x, JDBC and weblogic8.1sp6. the structure of the application is like this, jsf bean calls facade bean(which is stateless session bean) method. facade bean method calls dao method to perform database insert/updates. the trasaction attribute of facadebean's method is set to required in ejb-jar.xml.
now I create connection in the dao method and pass that to further dao methods. I have connection.setAutoCommit(false) in the dao methods. Problem is that in case of exception, rollback is not working. whatever updates are performed before the exception, get commited to the database, whether I specify rollback in the catch block or not. If I rollback in the dao method, I get the following exception when trying to rollback.
can anyone help me please?


here are my methods

   
==============FACADE=============================================
 
public void edit(AuditData audit_data, ApplicationVo p_vo)
throws appException {
try {
this.getDao().edit(audit_data, p_vo, null);
} catch (appException e){
throw e;
}
}
 
=====================  DAO METHOD ======================================================================
 
public void edit(AuditData audit_data, ApplicationVo p_vo, Connection c)
throws appException {
boolean connectionNull = false;
if (c == null) {
c = this.getConnection();
connectionNull = true;
}
try {
c.setAutoCommit(false);
} catch (SQLException e) {
throw new appException("edit: SQLException in connection setAutoCommit. "+ e.getMessage(), e);
}
try {
//perform some other update/insert/delete operations on a list in applicationVO
/*......loop over list
.....
*/
//then audit the changes, audit method also has the same structure.
this.audit(audit_data, c);
} catch (SQLException e) {
appLogger.error("edit:SQLException editing Atttributes " + e, e);
try {
c.rollback();
} catch (SQLException se) {
se.printStackTrace();
appLogger.error("edit: SQLException in connection rollback. " + e.getMessage(), e);
throw new appException("edit: SQLException in connection rollback. "+ e.getMessage(), e);
}
throw new appException("edit: SQLException. " + e.getMessage(), e);
}  catch (appException e) {
appLogger.error("edit:SQLException editing Atttributes " + e, e);
try {
c.rollback();
} catch (SQLException se) {
se.printStackTrace();
appLogger.error("edit: SQLException in connection rollback. " + e.getMessage(), e);
throw new appException("edit: SQLException in connection rollback. "+ e.getMessage(), e);
}
throw e;
} finally {
try{
if (connectionNull && (c != null)) {
c.close();
}
} catch (SQLException e) {
appLogger.error("edit:SQLException closing Connection.PreparedStatement. ErrorCode: "
+ e.getErrorCode() + " SQLState: " + e.getSQLState() + " Message: " + e.getMessage(), e);
}
}
}

================================================================  EXCEPTION =============================================
java.sql.SQLException: Cannot call Connection.rollback in distributed transaction.  Transaction Manager will commit the resource manager when the distributed transaction is committed.
        at weblogic.jdbc.wrapper.JTSConnection.rollback(JTSConnection.java:704)
        at com.sss.app.dao.OracleItemHelper.edit(OracleItemHelper.java:572)
        at com.sss.app.dao.OracleItemHelper.edit(OracleItemHelper.java:548)
        at com.sss.app.admin.facade.FacadeSession.edit(FacadeSession.java:573)
        at com.sss.app.admin.facade.Facade_r1e6m6_ELOImpl.edit(Facade_r1e6m6_ELOImpl.java:1015)
        at com.sss.app.admin.bean.BusinessDelegateBean.edit(BusinessDelegateBean.java:937)
        at com.sss.app.admin.bean.AssetAppsBean.edit(AssetAppsBean.java:152)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:132)
        at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:61)
        at javax.faces.component.UICommand.broadcast(UICommand.java:109)
        at org.ajax4jsf.framework.ajax.AjaxViewRoot.processEvents(AjaxViewRoot.java:180)
        at org.ajax4jsf.framework.ajax.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:158)
        at org.ajax4jsf.framework.ajax.AjaxViewRoot.processDecodes(AjaxViewRoot.java:274)
        at org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:32)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
        at org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:77)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1077)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
        at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
        at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:97)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
        at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127)
        at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
        at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:7053)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3902)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
        
===================================================================================================================================
 

[Paul Sturrock]

Are you calling setRollbackOnly() in your EJB method when you catch your application exception?

[Nitin Deshmukh]

no, I am not. how do I call setRollbackOnly method? as far as I know, there is no such method in the session bean.

[Nitin Deshmukh]

hi,
found out that setRollBackOnly() is a method of EJBContext. used and tested this method in a dummy method and it seems to work.
thanks a lot for the response.

[Paul Sturrock]

Originally posted by Nitin Deshmukh:
hi,
found out that setRollBackOnly() is a method of EJBContext. used and tested this method in a dummy method and it seems to work.
thanks a lot for the response.

Yes indeed, it is called on the EJBContext. This is one of the cornerstones of EJB CMT. An EJB method that is running in a container managed transaction needs to know when an exception == a transaction rollback. It is perfectly possible for your method to handle a situation where you encounter an exception and you want the transaction to be committed anyway. So you need to tell the container that it should rollback via setRollbackOnly().