Head First EJB - Mock Exam question 49 (page 673)
Morgan Bath
Ranch Hand
Posts: 196
posted 13 years ago
Which are true about transactions in EJB 2.0? (Choose all that apply.)
And one of the 'ticked' correct answers is:
C. Entity beans with BMT demarcation must use the getStatus method instead of the getRollBackOnly method.
Did I read the book wrong or the question?
And one of the 'ticked' correct answers is:
C. Entity beans with BMT demarcation must use the getStatus method instead of the getRollBackOnly method.
Did I read the book wrong or the question?
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Sudhir V
Ranch Hand
Posts: 143
Morgan Bath
Ranch Hand
Posts: 196
posted 13 years ago
WHats an errata list?
Originally posted by Sudhir Vallam:
Ya you are right. Since entity beans are not allowed to use BMT so the choice is wrong. Someone had pointed this error before but I could not find it in the errata list. I went ahead and submitted it.
WHats an errata list?
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Philippe Maquet
Bartender
Posts: 1872
Philippe Maquet
Bartender
Posts: 1872
posted 13 years ago
Hi Morgan,
I confirm your're right I noticed that mistake in early December along with three other ones.
I didn't post them in the "Unconfirmed error reports and comments from readers" section of HF EJB errata, but to Kathy Sierra directly (December 13).
Here are they (but never confirmed):
--------
49 (p673) : C is mentioned as "true" : "Entity beans with BMT demarcation must use the getStatus method instead of the geRollbackOnly method.
Incorrect because entity beans don't support BMT.
--------
56 (p675) : As the relationship is bidirectional and one-to-one, "A" should be checked too IMO (f1.getBar() == null).
--------
57 (p676) : C is mentioned as "true" : "If two entity object references are compared using the isIdentical() method, the container will return true if the two entity objects have the same primary key".
The conditions are same primary key *AND* same home.
Specs p. 120 : "Every entity object has a unique identity within its home. If two entity objects have the same home and the same primary key, they are considered identical."
--------
58 (p676) : "Which will return a set of customers that have orders?". D. (SELECT OBJECT(c) FROM CUSTOMER c, Order o WHERE c.custnum = o.custnum) is said "false".
I am less sure about this one, but I think it should be "true". The specs say "If a query for a select method whose result type is java.util.Set does not specify DISTINCT in its SELECT clause, the container must interpret the query as if SELECT DISTINCT had been specified."
As you mention the result type to be a set (which I interpreted as a java.util.Set), I concluded that the query was defined for a select method. If that's correct, then it's clear that the DISTINCT keyword is optional.
Best regards,
Phil.
I confirm your're right I noticed that mistake in early December along with three other ones.
I didn't post them in the "Unconfirmed error reports and comments from readers" section of HF EJB errata, but to Kathy Sierra directly (December 13).
Here are they (but never confirmed):
--------
49 (p673) : C is mentioned as "true" : "Entity beans with BMT demarcation must use the getStatus method instead of the geRollbackOnly method.
Incorrect because entity beans don't support BMT.
--------
56 (p675) : As the relationship is bidirectional and one-to-one, "A" should be checked too IMO (f1.getBar() == null).
--------
57 (p676) : C is mentioned as "true" : "If two entity object references are compared using the isIdentical() method, the container will return true if the two entity objects have the same primary key".
The conditions are same primary key *AND* same home.
Specs p. 120 : "Every entity object has a unique identity within its home. If two entity objects have the same home and the same primary key, they are considered identical."
--------
58 (p676) : "Which will return a set of customers that have orders?". D. (SELECT OBJECT(c) FROM CUSTOMER c, Order o WHERE c.custnum = o.custnum) is said "false".
I am less sure about this one, but I think it should be "true". The specs say "If a query for a select method whose result type is java.util.Set does not specify DISTINCT in its SELECT clause, the container must interpret the query as if SELECT DISTINCT had been specified."
As you mention the result type to be a set (which I interpreted as a java.util.Set), I concluded that the query was defined for a select method. If that's correct, then it's clear that the DISTINCT keyword is optional.
Best regards,
Phil.
