Janne Karhu

I passed the exam today. It wasn't very difficult. I had few tricky questions, but mostly the questions were reasonable. I lost 2 questions on EJB-QL even though I was confident I answered correctly... I suggest you to study CMP (with DD tags!) and life-cycle things carefully if planning to go to the exam.
I had 40 minutes spare time after checking items I had marked (less than 10).

To my knowledge, everything residing in the same JVM than the bean can access the bean through local interfaces. Thus the answer is "yes".

If the message producer uses "store and forward", the message producer is able to spool the messages to the local store until the MOM (your JMS server) is reactivated (server is started again).
Another thing that can be down is the consumer; the specific EJB server containing the consumer can be down, and the MOM persist the messages until the consumer is up again.
More information can be found from Internet or from "Mastering EJB 2", page 204.

Originally posted by Rashmi Tambe:
Hi All,
EJB spec Page 314, topic 15.4 states that-
Durable topic subscriptions, as well as queues, ensure that messages are not missed even if the EJB
server is not running.
How is this possible? If the server is not running, then even the JMS message service is down. Then who will
receive the message sent by the message producer/publisher? In HFE, page 450, says that-
Topic subscriber can request a durable subscription if he wants to make sure that he sees all messages
including the one that accumulated while he was offline
I think this meaning of durable subscription makes sense than in EJB spec. Can some body clarify this?

If object1 == object2 returns true, they reference to the same object. But if object1 == object2 returns false, the objects may still refer to the same entity (i.e. the primary key objects contain the same data which implies that equals-method returns true).
Thus, only B is correct.

Originally posted by Rajnish Bhasin:
I guess there can be BMT Entity beans(What if u use Bean Managed Persistence and want to manage yr Transactions), just that the exam is not supposed to cover such a thing.

The spec says in page 339 that "An Entity Bean must always be designed with container-managed transaction demarcation". Of course you can speculate whether the "must be designed" implies that entity beans can still use BMT but must only be designed for CMT... Any other opinions?

In page 665 the answer to question 19 states that no reflection should be used when programming entity bean class. In my opinion the question is badly worded; since there are no number of correct answers given in the question and the EJB spec does not absolutely deny the use of reflection (instead the spec denies some specific use of reflection), it's very difficult to guest whether to select B or not.

In page 673, the answer to the question 49 states that correct answers are E and C. However, the only correct answer should be 'E'; 'C' must be incorrect because there is no such thing as BMT entity bean.

It's very easy to distinguish whether the exception is an application or a system exception; all exceptions inherited from RuntimeException are system exceptions. All the other exceptions (EXCEPT java.rmi.RemoteException) are application exception.
J2EE 1.3 api (javadocs) is very helpful..

Where have you found that info? In the general case, I think that the container does not have to call ejbStore() before ejbRemove()..

I think you are right (at least from the client point of view) - please examine OID figures from pages 90-93 (OID=Object interaction diagrams) in the EJB 2.0 specification.

Originally posted by si yi:
First client can invoke create() and remove() on stateless session bean
when client invoke create() on it just create EJBObject
when client invoke remove() on it just kill EJBObject.
above is my understanding, is right?

Thanks for your replies. I understand your point - the 4 methods of SFSBs are in the unspecified tx context and thus no set/getRollbackOnly() can be called. Anyways, in page 81 of the spec it is also said:

The reasons for disallowing the operations in Table 2 follow:
...
� Invoking the getRollbackOnly and setRollbackOnly methods is disallowed in the
session bean methods for which the Container does not have a meaningful transaction context,
and to all session beans with bean-managed transaction demarcation.
...
� 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.

This quote is very annoying from the logical perspective; how come the 4 methods can access resource managers and ejbs (and thus they seem to have meaningful tx context), but they cannot access the aforementioned get/setRollbackOnly() methods (and thus they do not have a meaningful tx context ?

I'm aware that BMTs can never call get/setRollbackOnly() (at least not without getting IllegalStateException), but the page I mentioned in the spec claims that even CMT beans cannot call those methods in ejbCreate/Remove/Activate/Passivate.

Originally posted by Viktor Sadovnikov:
Hi,
"All possible bean things" are allowed in BMT stateful session beans only. But when you use BMT, you are not allowed to use get/setRollbackOnly(). Instead you can call commit() or rollback()
Regards,Viktor

Does anybody know why ejbCreate/ejbRemove/ejbActivate/ejbPassivate -methods for SFSBs are allowed to do every possible bean things except call get/setRollbackOnly() (EJB 2.0 spec in page 80)? I assume there exists a meaningful tx context in those methods since it's allowed to call other beans and access resource manager from them.

With CMP, you must only implement 3 and 4, but you can also implement ejbSelect -methods. However, the name of ejbSelect -method can never be just "ejbSelect". With BMP, you must implement 3 and 4 (as with CMP), but you could also implement finder methods (if you have specified finders other than findByPrimaryKey in your home interface). Again, the name of the finder cannot be "ejbFind".
So the answer is clearly "3 and 4".

Originally posted by sonali rao:
Mock exam question: which of the follow methods must the bean provider implement in an entity bean class? 1.ejbFind 2.ejbSelect 3.unsetEntityContext 4.ejbLoad 5.setRollbackOnly

Ok, how about this:
TestBean.java:
...
private SessionContext ctx;
...
public void myBusinessMethod(...)
{
Client client = new Client();
client.doStuff((TestLocal)ctx.getEJBLocalObject());
}
public void anotherBusinessMethod()
{
//do anything
}
...
Client.java: (acts as a client for TestBean)
...
public void doStuff(TestLocal tl)
{
//see? This method gets a local component interface as a parameter!
tl.anotherBusinessMethod();
}
...
[ February 27, 2004: Message edited by: Janne Karhu ]