Howdy all, here is an example of the way transaction attribute questions appear on the exam:
Assume that the image describes method invocations and shows the transaction context in which each of the methods will run. Assuming that all methods run without exception, which of the following shows transaction attributes that will produce this scenario? (In the diagram, a ___ indicates that there is no transactional context for the method) Answer options: A) Method R - RequiresNew Method S - Supports Method T - Required Method U - NotSupported Method V - Supports B) Method R - Mandatory Method S - Required Method T - Mandatory Method U - NotSupported Method V - Never C) Method R - RequiresNew Method S - Mandatory Method T - Supports Method U - Never Method V - NotSupported D) Method R - RequiresNew Method S - Mandatory Method T - Required Method U - Supports Method V - Supports Hope I didn't mess this one up... anyway, this almost identical to the way the questions are formatted -- with a diagram and then the answers are the methods with attributes next to them. Note: there are several different ways in which the combination of attributes could produce the scenario in the diagram, but of the answer options given, only one will work. cheers, Kathy
Follow my thought, TXs are not the most difficult part of the exam : The cruicial point is method R. The only attribute that allows us to start a new transaction from within the current one is RequiresNew. Thus, we leave out option B, because Mandatory attribute will cause the transaction Foo to be propagated to the method R. Let's take option C. R - ok S - ok T - ok. As we have TX foo from Method Q, we will re-use it. U - here we have a problem. Never forces you make a call without a transaction context. If you call it with a transaction already registered, a RemoteException/EJBException is thrown. Option C goes out. Option D. R - ok S - ok T - ok U - a problem. A Supports TX attribute allows the method to run with or without TX context. If there were a transaction already, we would join it. Otherwise we happily run without a transaction at all. Note this is not an option for Entity Beans, where you always have to run within a transaction context. What left? Option A, let's check it. R - ok S - ok T - ok U - ok. Here's the trick. In method U we run without a transaction, but the previous transaction still exists and is suspended. V - ok. Method U (no TX) calls method V. method V doesn't see the suspended transaction, it sees only what it's caller (U) has. As the attribute is Supports and we have no previous transaction, we do not create one, but run without a TX.
Hope this helps, and you are not lost yet Please, see section 17.6.2, page 357 of the spec. It has a nice summary table at the end as well. P.S.: SCBCD seems to be the funniest exams of all by far with all those schemes, drag-n-drops. What other surpises do you guys have in your sleeve? [ May 28, 2003: Message edited by: Andrew Perepelytsya ]
Andrew, you are awesome. And your thoughts on this are exactly right.
Originally posted by Andrew Perepelytsya:
P.S.: SCBCD seems to be the funniest exams of all by far with all those schemes, drag-n-drops. What other surpises do you guys have in your sleeve?
Ahhhh... there are one or more questions that involve stories/scenarios. LIke, "A Bean leaves Chicago travelling at 60 Kilometers an hour while another Bean leaves Los Angeles heading east... [more stuff], How fast does Bean B have to go in order to intersect Bean A in Denver Colorado?" That sort of thing. Except more about transactions or exceptions or some other bean-related strategy. And then there are the questions where YOU have to draw a picture of a Bean, with a face and hair and everything, and you're judged on your artistic interpretation of the bean's role in the specificaion. You'll just love it! -Kathy
And then there are the questions where YOU have to draw a picture of a Bean, with a face and hair and everything, and you're judged on your artistic interpretation of the bean's role in the specificaion.
Oooh, should I have an arts degree as a pre-requisite? After all, I seem to be moving a 'completely wrong' direction with all that Java...
I still don't understand why D is incorrect. Choice U and V "supports". Also T (the client) is shown to have the Tx foo. Won't both U and V run under T's transaction context ? (U run under T and V run under U) The specs for Supports say "If the client calls with a txn context, the container performs the same steps as described in the Required case". Here the client T definitely has a txn context foo. Thanks, Sudd
Andrew - Thank you a lot for the clarification. I incorrectly assumed "---" meant "ignore or don't care" meaning anything possible. After analyzing this question, now I think I understand txns better. Thanks and regards, Sudd
SCJP 1.4, SCWCD, SCBCD 1.3
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop