Jim Richards wrote:
> 
> I have been going through the old messages and having a few problems
> myself with rollbacks. I noticed two other people having the same problem,
> but I didn't see any resolution to it.
> 
> I have a session bean that, takes in data from an servlet form, and
> uses two entity beans to update two different tables. If some business
> rules fail (check for valid update), then I throw an exception and expect
> the data to be rolled back. I have made sure the transaction all occur
> in on transaction (there are no TX_REQUIRES_NEW attributes, but some
> TX_MANDATORY to ensure they are all in one transaction).
> 
> I can get around the problem by doing all the checks first, but I was expecting
> the rollback to occur. I'm using Postgres which handles transactions, and
> isolation levels as well (which is kinda nice)
> 
> Going through the code I see (in Bull<BeanName><BeanRemoteName>.java
> generated by GenIC -keepgenerated) that before my method is called, we
> have a call to
> 
>         preinvoke(home, 2)
> 
> where home is the home interface to create the new bean and 2 is the transactional
> attribute (TX_REQUIRED) ...
> 
> and when it is over in a finally block we have
> 
>         finally {
>             postinvoke(2);
>         }
> 
> which will commit the transaction, in the catch part of the code we have several
> calls to a function called
> 
>         onUncheckedException(e);
> 
> which is defined as
> 
> public void onUncheckedException (Throwable ue) throws java.rmi.RemoteException {
>         Trace.outln(trace, "BullBean.onUncheckedException(Throwable 
>"+ue.toString()+")");
>         // TO BE DONE
>         return;
>     }
> 
> Digging around I can see that the sessionContext has a method called
> setRollbackOnly() which, when set will cause the transaction to rollback,
> and this boolean is checked with the postinvoke to see if the tranaction is
> to be committed, but I cannot see where this might be set if there
> in an exception, and nowhere do I see the rollback called if this is
> what is meant to happen ...
> 
> Without rollbacks, Jonas doesn't really comply with the EJB Specification ... and 
>that'd
> be bad ...

Hello,
We have modified JOnAS to correct problems that were reported about
exceptions and rollback.
I think now we are more compliant to the EJB1.1 specification (cf � 12
and Table 8 container responsabilities for handling exceptions)
However is it possible that some problem remains when exception are
raised
in ejbCreate, ejbPostCreate, ejbRemove and ejbFind<METHOD> that must be
considered
like business methods but aren't in JonAS.
You can find the correction in the CVS version of JOnAS.
It will be fine if you could confirm that your problems are solved
Now we can work to treat correctly ejbCreate,... methods.
thanks,

-- 
        Philippe

Philippe Coq  Groupe Bulll/BullSoft/OpenMaster  Phone: (33) 04 76 29 78
49
Bull S.A  - 1 rue de Provence - 38432 Echirolles Cedex France
[EMAIL PROTECTED]  http://www-frec.bull.com
Download our EJBServer at http://www.bullsoft.com/ejb

Reply via email to