Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Girija Siva

Ranch Hand
+ Follow
since Apr 23, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Girija Siva

Thanks Mark
This was very helpful
16 years ago
Hi Karthik
Even this is already posted and there are discussions on this. Search the mailing list
:-) So that's what the spec says karthik
Thanks Vipin
Hi Mini

1. How can ejbActivate, ejbPassivate and ejbRemove methods in stateful Session bean, can get the transaction reference and call methods on it but cannot do CMT related transactional operation.

Note fropm the spec that all these methods are running in unspecified transaction context.
For a CMT the container starts a transaction and we don't know exactly when , but we can rely on the SessionSynchronization call backs to do things just before transaction starts etc.

For BMT you are creating the transaction and then managing transaction .

So my conclusion is as these methods are not controlled by transaction you can't set rollback or get rollback in these methods.

2. Why is ejbRemove in Stateful Session bean has different level of usage of SessionContext than Stateless Session bean. I know about the client security context, but what about transaction references and other things.

from the spec" Accessing resource manager 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"

3. HFE Page 236, What does this means - "The bean class is not required to (but is allowed to) implement the bean's component interface.

Implementing component interface is bypassing the container. The container or spec won't stop you from doing it. It is allowed. But it is no more J2EE in spirit as you will be bypassing all the services the container is providing and also the body guard. It is not at all advised
My hearty Congratulations Roger. Thanks for the detailed post
Time to celebrate
16 years ago
Thanks Roger Can you plaese refer to the page of the spec that makes this mandetory
You will also find that ejbCreate() method is called when EJBObject is already made available by the container.

The timeline of create() on home and ejbCreate() on bean are unrelated is it not.
Per say, the container creates beans and puts them in pool. It calls ejbCreate() as part of the bean creation. At that time there is no client create call on the home.
EJBObject is created as part of the client create() call at a different time.
When is it the EJBObject is associated with the bean???
When ejbCreate() is called there is no client=> no call create() on home=> no creation of EJBObject , how is it EJBObject is available at the time of calling ejbCreate(). What is it I am missing in here
Thanks in advance
Hi Roger
Good luck with your preparation and the exam

The remote client of a bean invokes the remove method. Under what circumstances will the client receive a:

(a) javax.ejb.RemoveException

the client gets this exception for stateful and entity when something goes wrong while calling remove or the bean provider throws this

(b) java.rmi.RemoteException

the remote client gets this when there is a system exception

(c) javax.ejb.EJBException

the local client gets this when there is a system exception

(d) java.rmi.NoSuchObjectException

the remove client still has the stub but the remote object is no more associated with it
Don't get confused between CMP and CMT Entity beans are always CMT whether they are BMP or CMP
What do u mean by comparing two stateful objects. If u want to see if they represent same client or not(same bean) you can use isIdentical(). It will return true if both ur references are using the same Bean

It's almost as if the bean class is implementing a hidden interface which has this method declared:

Is there some good reason ejbCreate() is not declared in javax.ejb.MessageDrivenBean?

The way I look at it is the developers only way to participate in beans creation. Obtain resources that are required or do things like that if business needs it. Without this method there is no way for the developer to say a word in beans creation
The ejbCreate is in bean class and for other beans it has got matching create() in the home interface for the client to initiate the creation. But in case of MDB there is no matching as there is no client and no HOME. Observe even in case of Staless SessionBean even if there is matching create it has nothing to with the ejbCreate() in the bean class.

This is a very nice point you raised Roger. I did not looked at ejbCreate() and create() this way before.
This is what My understanding is ..IF anyone has more to add......
Hi Roger
I did not get what ur saying but ...

As you all know, every bean class must declare at least one ejbCreate() method (unless it's a stateful session bean whose home interface has no create() method).

create is mandetory for SessionBean , optional for EntityBean and no create as there is no home interface for MessageBean Is it not.? Am i missing something fundamental here in understanding what ur trying to say???