Hi
In the
Srindhar Rama's mock exam question 29
16. Which of the following are true about the Primary Key class in Entity EJB?
a. It is used for identifying an Entity BEan according to the Bean type, remote interface and Container Context
b. It is used for identifying an Entity BEan according to the Bean type, home interface and Container Context
c. The definition of the Primary Key can be deferred until deployment
d. The primary key should override the equals() and hashCode() methods of the Object class
e. The primary key class cannot define constructors
the author's answer was b,c,d. I wonder about answer c. Even though one could always change the primarykey class in descriptors he/she still has references to the primarykey class wherever session beans or clients (in theory) called the findByPrimaryKey() methods on the home object. If the PK is changed from Integer to ProductPK ( arbitrary example) then there might be few changes to do in the code. those changes are likely to be fairly simple and we should know where they are needed, however i am not sure if such changes are considered to be part of deployment since changes are made to the code itself. So can answer c be part of the correct answers?can you really deffer PK class untill deployment?
29. When does an Entity Bean transition from Pooled State to Ready state
a. when create() is invoked on EJBHome
b. when a find method is invoked on EJBHome
c. when a BEan is activated by the container
d. when a BEan is passivated by the container
according to the suthor the correct answer is
a,b,c.
In MasteringEJB by Ed roman it says that finder methods are served when the been is pooled but dont get it to the Ready state, rather the bean is still in a pooled state.
next one might just be a matter of "game of words"
30. When is unsetEntityContext() invoked on an Entity bean?
a. When the entity bean is to be garbage collected
b. After an entity bean is garbage collected
c. after the finalize() method has been invoked on the EntityBean
d. None of the above
the author's answer is a. However to me at least it sounds like "because the bean is to be g.c the container calls the unsetEntityContext()" while the way I got it (please correct if i am wrong), first the container calls the unsetEntityContext when the container decides the bean is not needed and as a result of that after unknown time and after the container released all references, the gc will be called and do the do.
My only problem with answer a is that it might imply that unsetEntityContext is called because the gc is to perform while it is the other way around. my answer was d.
another one is
27. In EJBs, Which two callback methods can be used for synchronizing the bean's state with the database
a. ejbStore() and ejbLoad()
b. ejbActivate() and ejbPassivate()
c. ejbStore() and ejbPasivate()
d. ejbLoad() and ejbActivate()
the author answer was b. However its the ejbStore and ejbLoad that interact with the database. they are called as part of the activation and passivation but the ejbActivate and Passivate themselves dont interact with the database.
from MasteringEJB:
"entity beans are routinly synchronized with a database via its store/load operations."
(page 426)
and last one
28.Which type of EJBs are ideal to model multiple rows of read-only data?
a. Entity Beans
b. Session Beans
I assume this is debatable and can be a ground for design discussion.the author answer is b. However entity beans can be used for that as well and might be prefferd since they automatically synchronise themselves with the data in the database using the ejbLoad and on the other hand never call the ejbStore since they are read-only and never change. Is it really ideal to implement this using Session beans or Entity beans?
I might be wrong, so would love to hear other opinions.
cheers
shai
[ May 06, 2002: Message edited by: shai koren ]
.