Arun

Hello all,
In reference to the following snippet found in the DD:
<message-driven-destination>
<destination-type>javax.jms.Topic</destination>
</message-driven-destination>

Why does the bean provider have to tell the bean deployer the destination-type to which the bean is listening for? Is there some coding in the bean that relies on the destination type? All the bean will be concerned about is that it get's a message. The message producer will have to be concerned about whether to send a message to a topic or queue, not the listener(bean).

Am i missing something?

In pg 559 of HFEJB it says that when a client calls remove() on a bean that has already been removed, the client will get a EJBException or RemoteException.I was wondering why it is not NoSuchObjectException/NoSuchObjectLocalException. Isn't that the exception thrown when you try to invoke a business method on a bean that has already been removed??

Hello all,
I could not find answers to all the scenarios in page 556, here is a compilation of answers(mine and borrowed from forum). Please post your comments if anything is wrong:

1. A message-drive bean's onMessage() method catches an application exception. Can it rethrow the application exception to the container?
-- No, the onMessage() method does not declare any application exceptions and hence cannot throw the application exception. It can wrap the exception in a runtime exception and rethrow it.

2. A session bean using CMT has a method marked with the NotSupported transaction atrribute While the method is running. the bean calls setRollbackOnly() on its context. will this cause an exception? What kind?
-- Yes, it will cause an exception. It will be an illegalStateException.

3. A message-drive bean, in the onMessage() method, calls getCallerPrincipal(). What happens?
-- Again, an illegalStateException is thrown

4. A session bean using CMT has a method marked with the Madatory transaction attribute. The client calling the method is not in a transaction. What happens?
-- TransactionRequiredException/TransactionRequiredLocalException is thrown.

5. A bean realizes it can't commit a transaction, but it doesn't want the client to get an exception. What can the bean do?
-- Call the setRollBackOnly method and simple suppress the application exception.

6. A bean wants the client to get an application exception, but the bean still wants the transaction to commit. What should the bean do?

-- Simply throw the Application exception as is. It does not have to do anything more.
Regards.

I think the following are the answers:
1. A
2. D
3. C, D
4. A.

A followup question: say clientA loads entityA and invokes the setState() and goes on to do something else without finishing the transaction. Then, clientB executes a finder method to find all entities with a particular state, since the record loaded by client A is locked, will the find method wait till clientA releases the record?

I dont have the book with me now, but may be the reason it is invalid is because the return type should be the primary key class and not a primitive type??? So if the return type was Integer instead of int it would be valid then.

Thankyou for your responses. It makes things clear for me now.

I have a client that gets a reference to an entity bean A. Say it calls enityA.getCity(). Now if another client calls entityA.getState(), will this have to wait untill the first caller is done with the transaction(it entered into when it called getCity())?

Thanks,
Arun.

True, you cannot predict when the ejbCreate() method will be invoked. I use JBoss, and I noticed that when I start up the server, it displays the output from the ejbCreate() print statements. So my installation of JBOss was configured to create beans on start up. It all depends on the container and your configuration.

Thanks Satish and Roger. As Roger says, I would implement a shopping website with SLSB's. Store the items a shopper adds to a http session and finally when he checks out, call a business method on a SLSB to do all the business logic. If i took the SFSB approach, for every item the shoppers adds to his cart I would be making RMI calls to some method in the SFSB, which is not that efficient.

Hello,
I am trying to think of an application or some scenarios where I would use stateful session beans. I know that when I need to maintain state I need staeful bean, but a more real world example would help me understand better. Almost always I feel a stateless session bean would suffice. Could someone who has used stateful session beans give me an example of where you used stateful session beans?

THanks.

Adding more to the posts earlier note that, with BMP you still get the connection from the container and the container manages the connections. Also, things like when a bean has to be stored or retrieved from the database are the same for CMP and BMP. The difference is that in BMOP you write the queries that need to be executed for doing the CRUD operations. With CMP the container generates the queries for you.

Adding more to the posts earlier note that, with BMP you still get the connection from the container and the container manages the connections. Also, things like when a bean has to be stored or retrieved from the database are the same for CMP and BMP. The difference is that in BMOP you write the queries that need to be executed for doing the CRUD operations. With CMP the container generates the queries for you.

Home interfaece, as the name indicates is the home, from where you get references to the component interface. The home has the create methods that clients can call to obtain a reference to the component instance.
The component interface is what has the business methods you are interested in. It is the actual thing that you are likely interested in.
Hope this helps.

A quick google on your error returned the following page.
http://java.sun.com/j2se/1.4.2/docs/guide/idl/jidlExceptions.html
Do you by any chance have multiple instance running or something that is causing port conflicts?

Also, if no one has responded it is probably becuause they do not have an answer. every one here was a newbie sometime or the other.