More on Exceptions !

[Reghu Ram Thanumalayan]

Hello guys,
In the chapter Exceptions in HFE (page 556) under the various scenarios, it’s given that
1.A message driven bean’s onMessage method catches an application exception. Can it rethrow the application exception to the container?
I guess the answer here is no but what will happen if the bean re-throws the exception to the container?
2.A bean realizes that it can’t commit a transacton. But it doesn’t want the client to get an exception. What can the bean do?
I want to know the answer for this question.
3.A bean want the client to get an application exception but still wants the transaction to commit?
In this case the bean should throw the application exception to the container. Is this answer correct?

[Philippe Maquet]

Hi Reghu,

1. A message driven bean�s onMessage method catches an application exception. Can it rethrow the application exception to the container?
I guess the answer here is no but what will happen if the bean re-throws the exception to the container?

The code wouldn't even compile, as onMessage() has no throws clause (application exceptions are *checked* ones).
2. Calling setRollbackOnly().
3. Yes
Best,
Phil.
[ December 18, 2003: Message edited by: Philippe Maquet ]

[Reghu Ram Thanumalayan]

Hi ,
Very nice to see prompt replies from this forum. I have begun to like JavaRanch very much... JavaRanch rulez.......
For the second question i asked,

2. A bean realizes that it can’t commit a transacton. But it doesn’t want the client to get an exception. What can the bean do?

I want to know, how can the bean make sure that the client doesn't get an exception after calling setRollbackOnly() . I am not able to visualize the scenario in which it would happen. Can u help me with a detailed scenario where this would happen ?
Thanks Phil for prompt replies,

[Philippe Maquet]

Hi Reghu,

how can the bean make sure that the client doesn't get an exception after calling setRollbackOnly()

Well, the bean provider cannot *make sure* the client will not get some exception. After all the container could send the client some RemoteException for some "personal" reason. The question was different though : "But it *doesn�t want* the client to get an exception. What can the bean do?". From the bean provider view point, the least it can do (after the call to setRollbackOnly()) is to avoid throwing such an exception by himself.
Best,
Phil.

[Vladas Razas]

Hey,
If the bean throws application exception, container throws exception to client but does not rollback transaction. What can client do if it was CMT bean (remember CMT transaction ends when the method ends?). So what we will get... we pass control to the client and the transaction is still not rolled back? How can that be with CMT?

[Sunil Patil]

If the bean throws application exception, container throws exception to client but does not rollback transaction. What can client do if it was CMT bean (remember CMT transaction ends when the method ends?). So what we will get... we pass control to the client and the transaction is still not rolled back? How can that be with CMT?

What i understand is in case of CMT if you dont throw System exception and dont call setRollbackOnly() then container will commit the transaction when method ends. In case of CMT it is not possible for transaction to be in a state other than commited or rolled back by the time client gets control.
Sunil