Constantino Cronemberger

I did it in almost 1h.
In the mock exam I did 87%.
I found the real exam much easier then the mock one.

Have a look at section 10.3.6 of the spec.
When you add the salesrep to sfOffice it gets removed from nyOffice because the relationship is one-to-many, and that means that a given salesrep can be in a relationship with only one office. So if you add it to nyOffice it has to be removed from sfOffice otherwise the multiplicity restriction would be broken.

Your example is not always wrong. It depends on the multiplicity of the relationship. In this case the options are one Office to many Salesrep or many Offices to many Salesrep (one-to-many or many-to-many).
If it is many-to-many there is no problem with this example, because the add act as a copy operation, not a move.
If it is one-to-many it is indeed wrong, because in doing that you are removing the iterator's current element from the collection and it will invalidate the iterator. What would be the current element after such a removal?
An alternative and cleaner way of doing this transfer would be:
sfSalesreps.addAll(nySalesreps);

IMHO, when getEJB(Local)Object is called from ejbCreate (for SLSB), and there is no EJBObject created yet, the container will create one just as like when the client calls create.

To run your client program you have to use the runclient.bat script.

Another interesting thing to notice on page 80 of the spec. is that on ejbCreate you can access "enterprise beans" even though there is no meaningful transaction context. This goes against what is said on page 81:
"Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the Container does not have a meaningful transaction context or client security context."

On page 90 of the spec. it says you can call getUserTransaction for BMT, but it does not say you can call methods on this UserTransaction.
Have a look at the business method row. There you can find the line "UserTransaction" methods.

Can anyone give me an example that illustrates the third paragraph on page 450 of the spec:
"If transactional requests within a single transaction arrive from multiple clients (this could happen if there are intermediary objects or programs in the transaction call-chain), all requests within the same transaction must be associated with the same security context."
Thanks.

Maybe you should try WSAD 5. I am almost sure WSAD 4.0.6 does not support EJB 2.0.
Once I have tried to create a finder method for an entity in WSAD 5, but it did not work when I was playing with parameters.

And there is one more point to this question. If that statement on page 353 of the spec is really right, it means that the example given on page 504 of the Head First EJB book is wrong, because it refers to methods on different beans in the same container-transaction element.

Is it true that for CMP Entity Beans, all select methods, and all finder methods but findByPrimaryKey must return a collection (or set)?
I made this supposition based on the fact that for CMP the container is responsible for generating those methods base on the EJB-QL for each method, and in the EJB-QL language there is no way to force the result to be just one value or row.
If it is not true, I have another question: How does the container decide which value to return from the result set? Does it take the first element? Or does it raise an exception when the result set has more then one element?

Hi there,
One of the reasons we can�t access client info from the SessionContext object in an ejbRemove for an stateless session bean is that this callback is not triggered by means of the client, and so it does not make sense, since there is no client involved.
But for stateful session beans there is a circumstance under which the ejbRemove is triggered without the client calling remove explicitly, and it is when the bean times-out in the active state.
In this situation, how is the container supposed to provide the client info? Should it keep this info from the last business method call made by the client?
According to the specs (7.6.1), the methods getCallerPrincipal and isCallerInRole are callable from ejbRemove.
These questions also apply to the ejbPassivate method, that is also triggered by a timeout, and not directly by the client.
Constantino
[ March 03, 2004: Message edited by: Constantino Cronemberger ]