It's not a secret anymore!*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes exceptions.. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "exceptions.." Watch "exceptions.." New topic
Author

exceptions..

Krishna Thotakura
Greenhorn

Joined: Feb 12, 2004
Posts: 6
Here is a question from www.ejbcertificate.com.
-------
Which of the following statements are true when a session bean's client receives a java.rmi.RemoteException? [Check all correct answers]

1. The container does not throw the java.rmi.RemoteException if the container performs a transaction rollback.
--------
1 is marked correct.
I do not understand why. if the business method of a remote session bean throws a system exception, wont the container rollback the transaction and throw a RemoteException for the client ???
what do you think about the quality of questions on www.ejbcertificate.com ?
Thanks.


----<br />Krishna<br />SCJP2
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
This is a bad question, although figuring out why it had to be a bad question definitely helped to pound more info on transactions and exception handling into my brain! The relationship between transaction handling and exceptions has to be the one of the more arcane parts of the EJB spec. See spec section 18.3.1, table 15, pgs 375-376.
First, you could argue that there is unnecessary potential for confusion in the wording because there are two different ways to interpret the question:
A. "here is a statement of fact that claims to be true",
"now I'll ask you if such a thing is possible in the first place"
(in other words, can you recognize when a question is lying to you)
B. "here is a statement of prevailing conditions",
"now I'll see if you know what happens next under such circumstances"
At first I expected that one interpretation would at least yield a reasonable test of knowledge and the author was unaware of the other possible interpretation, but it turned out that both interpretations have problems.
Case A:
In this interpretation you are being tested if you know the answer to "is it possible for the session bean to receive a RemoteException if the remote bean's container performs a transaction rollback?". The answer is both true and false. False if the remote bean executed in the client bean's transaction and did a rollback (1st row of Table 15 in the spec), true if the remote bean executed in its own transaction or if the problem happened during a callback executing in an unspecified transaction context (2nd and 3rd rows of Table 15). The question doesn't provide enough info, so both true and false are possible conclusions and the question is thus arguably bad under interpretation A.
Case B:
So in this interpretation you are being asked 'what will the container do to the caller of the session bean on a rollback?'.
Let "B1" be a client bean using the session bean, let "B2" be the session bean ("B3" would be the remote bean used by the session bean, but we don't really have to factor anything about B3 into understanding this case). If B1 and B2 execute in different transactions, and B1 is a remote client of B2, then on a rollback the container will throw RemoteException (row 1, Table 15). If B1 isn't a remote client of B2, it'll never receive a RemoteException. If B1 and B2 share a transaction, it won't receive a RemoteException for a business method transaction rollback, although it could receive one because of communications problems or a container callback failure if the callback executes in an unspecified transaction context.
So no matter how you slice it, the question supports both a true and false answer. Bad as a true/false question, good as an exercise. :-)
[ March 07, 2004: Message edited by: Reid M. Pinchback ]

Reid - SCJP2 (April 2002)
Krishna Thotakura
Greenhorn

Joined: Feb 12, 2004
Posts: 6
Hi Reid,
I really appreciate your quick response.
Regarding CASE A that you described - "is it possible for the session bean to receive a RemoteException if the remote bean's container performs a transaction rollback?".
I think the answer is a definite Yes.
If the question was worded "will the session bean client receive a RemoteException if the remote bean's container performs a transaction rollback?".
Then my answer would be "No (not always)".
I was reading the portion of the Spec you pointed out. And i have another question with reference to Table 15, first row on page 376 :
B1.m1() has tx1.
It calls B2.m2() that has RequiresNew trans-attribute. Let us call this transaction tx2.
Now, if B2.m2() throws a system exception or error,
Then container will discard B2 and mark tx2 for rollback - right ? B1 will get a RemoteException or EJBException.
The spec says "If the client executes in a transaction, the client's transaction may or may not be marked for rollback" What does this mean ?
Under what circumstances will transaction tx1 be marked (by container) for rollback ?
If B1.m1() does not attempt to catch RemoteException/EJBException and let the system exception propogate through, then will tx1 be marked for rollback by the container ? Is that what the spec is talking about ?
Thanks.
Goan Balchao
Ranch Hand

Joined: Mar 25, 2002
Posts: 93
Really nice explanation Reid. Thanks for taking the time to point out all the scenarios.


Hemant Kamat<br />SCJP2<br />SCWCD<br />SCBCD<br />SCEA-I
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
The spec says "If the client executes in a transaction, the client's transaction may or may not be marked for rollback" What does this mean ?
Under what circumstances will transaction tx1 be marked (by container) for rollback ?
If B1.m1() does not attempt to catch RemoteException/EJBException and let the system exception propogate through, then will tx1 be marked for rollback by the container ? Is that what the spec is talking about ?

That's the only scenario I can think of. Not so much of an issue for RemoteException - since it isn't a runtime exception if the bean implementation of m1 doesn't throw RemoteException (which for EJB 2.0 you aren't supposed to do anyways), then it won't propagate to the container. For a local client the situation is different - EJBException is a runtime exception, so if you didn't think to try and catch it, it would propagate through to the container and m1's transaction would be toast.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: exceptions..