As RemoteException (or EJBException in the case of a local interfaces), with one exception:
If the bean method runs in a transaction that the client started the client will receive a TransactionRolledbackException or ransactionRolledbackLocalException
What you say is true for CMP, but for BMP you implement for each finder method in the home interface, a corresponding ejbFind method in the bean that returns (a collection of) the primary key.
Don't be. You are right. You CAN call the getEJB(Local)Object methods on the beans context after setSessionContext.
But since the supposedly correct answer to the question C,F,G excludes getEJBObject/getEJBLocalObject I suppose that the author wanted you to take the question quite literally:
getEJB(Local)Object CANNOT and hence MUST not be invoked on *EJBContext*, because they are not defined there, they are methods of SessionContext and EnityContext.
1. because the primary key must be a *class*, so int is not OK but Integer is
2. you are right, it is not legal to call getEJBObject() from within ejbCreate()
3. the question should have been: which methods run in an unspecified transaction context? Answer D,E, and F. For the others the spec defines the transaction context in which they must run.
According to the book most exam candidates got a score close to the final mock exam.
Here's my experience: the real exam is a lot easier (even apart from the fact that the number of correct options to a question is given in advance). Did the mock exam and got a score 50/70, day after that did the real thing score 6/70 (91%).
So don't panic: if you do the master test for the first time and pass, chances are *very* good you'll pass the real exam.
As for unsetEntityContext: if the container removes a *session* bean from the pool it calls ejbRemove on the bean prior to the removal.
But this can't be done for entity beans since creation/removal have a different meaning: ejbRemove is called prior to removing the physical entity itself (not the bean). The bean (now without an idenity) goes back into the pool. If the container decides it doesn't need the bean anymore it will call an additional callback method 'unsetEntityContext' to inform the bean of its intention.
Although they are *declared* in the remote home and component interfaces your bean code should not throw remote exceptions itself.
Instead, you should throw a javax.ejb.EJBException or (rethrow) a RuntimeException in the case of unrecoverable errors, or else an application exception.
