Vipin Mohan

Thanks guys !
Its clear now.

Cheers
Vipin

hi all

If we call wait() method within the finalize()method of an object, will it prevent the garbage collection of that object till notify() is called ?

Thanks
Vipin

hi friends

The answers are given as A and E for this question. Shouldn't it be B and D.
Select all pattern values of a LIKE expression that would identify a word starting with a �J� and having �on� as the last two characters.

A. �J%on_�
B. �J*on%�
C. �J%on*�
D. �J_on%�
E. �J%_on_�

Thanks
Vipin

hello Mini

In the example, the EJB object reference is obtained from the EJBContext and not as a method argument. So naturally this code is from an entity bean.
Unless it is explicitly mentioned that the reference is passed as a method argument, you should assume that it is from an entity bean, since only they can have primary keys.

Thanks
Vipin

hi Nick

Thanks for the reply. I have one more question. According to specs-
Durable topic subscriptions ensure that messages are not missed even if the EJB server is not running, while non-durable ones don't.

Is there no acknowledgement sent in case of non-durable subscriptions ? If yes, then why doesn't it cause a redelivery of the message when no acknowledgement is received ?

Thanks
Vipin

hi friends

How does the client of an MDB know if a message has been delivered or not ?
I read about the various acknowledgement modes. But I'm not clear how the client receives the acknowledgement ? Are they received by the client as messages ?

Thanks
Vipin

hi Sujatha

I think <prim-key-class> element is always required whether its a single field or a composite field primary key.

Thanks
Vipin

I think it is java.rmi.NoSuchObjectException if the client is a remote client or the javax.ejb.NoSuchObjectLocalException if the client is a
local client.

Thanks
Vipin

hi Suman

Yes, now I'm clear with the whole concept, thanks to you and Ramesh.
It was a very useful discussion.

Thanks again for your time.

Cheers
Vipin

hi Suman

Thanks so much for explaining, now I understand what you mean here. But I think that the problem would happen only if the bean is currently participating in a transaction and you try to start a new transaction in the same bean.
For example,

client -> Bean1's someMthd1() [Required] -> {
Bean2's invoke1() [Required]
Bean2's invoke2() [RequiresNew]
}
In this example, Bean2 is made to start a new transaction, while its already in an open transaction. Now there will be an exception, since nested transactions are not allowed.

But in your example,

client -> Bean1's someMthd1() [Required] -> Bean2's invoke1() [RequiresNew]

I think Bean1's transaction is suspended when it calls Bean2's invoke1 method. So the same bean won't have to start a new transaction when one is open.

What do you think ? Whatever you answer might be, my original question has now been answered. The only question left is whether your example will cause an exception or not.

Thanks a lot
Vipin

hi Suman

Thanks for the detailed explanation. However, I have a small objection. In this example, if the invoke1() method has a 'RequiresNew' transaction attribute, then the transaction of someMethod1() would be suspended and this transaction would proceed. Thats how 'RequiresNew' works, right ?

Thanks
Vipin

hi Suman & Ramesh

Isn't the stateless session bean a client of the stateful bean in this example ? A client can be any application or EJB which invokes the methods of the bean, right ? Do correct me I'm wrong here.

Thanks
Vipin

hi Ramesh

Now its very clear to me. Thanks so much. But just want one last clarification from you. From your explanation, I understand that the following statement from Head First EJB is incorrect - "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Please do confirm this. Do correct me if I'm wrong.

Thanks again.

Vipin

Thanks Suman !
But I still feel that I'm missing something about CMT stateful beans here.
The API states that
"The afterBegin method notifies a session Bean instance that a new transaction has started, and that the subsequent business methods on the instance will be invoked in the context of the transaction. "

But in Head First EJB, it is said that "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Don't you find these statements contradictory ?

And the statement "Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."
seems to support the first statement and contradict the second.

Can you advice ?

Thanks so much
Vipin

Dear Ramesh & Suman

Thanks for your answers. I have some confusion even now.
You have said that

A stateful session bean can span transactions even across different method invocations on the same bean.

However, on page 509 of Head First EJB, it is stated that
"CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Please advice.

Thanks
Vipin