At 10:59 20.03.2000 +0000, you wrote:
>Not sure what you mean. The exception thrown is a RemoteException on the
>first call of
>
>unit.addComponent(component, dateRa);
>
>so would I have to catch this and throw a different type of Exception? I
>don't really want to take care of rollbacks myself. I've tried this but to
>with no luck:
>
>public void addUnitAndComponents(BusinessUnitProps props,
> BusinessUnit unit = null;
> try{
> unit = buHome.create(props);
>
> Iterator iter = compToDateRa.keySet().iterator();
> while(iter.hasNext()){
> BusinessComponent component = (BusinessComponent)iter.next();
> java.util.Date [] dateRa = (java.util.Date
>[])compToDateRa.get(component);
> unit.addComponent(component, dateRa);
> }
> }catch (RemoteException e){
> throw new CreateException (e.toString());}
As CreateException is not a subclass of RuntimeException, you must have
declared it in your throws clause.
Declaring an exception other than RemoteException in your throws clause
makes the container treat it as an
application exception, which is defined in chapter 12 of the specification.
Application exceptions do not rollback
the client transaction.
In your case, the spec suggests throwing an EJBException ( which you don't
have to declare
in your throws clause because its a subclass of RuntimeException ) that
wraps the RemoteException.
Then its treated by the container as a non-application exception and the
transaction should be rolled back automatically.
Hope that helps ( ...and is correct ;-) ).
--jochen
(-) Jochen Strunk
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665402, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
